Re: [PATCH] trace/wscript: Improve C++ standard selection

[Chris Johns]

On 3/8/2023 5:36 pm, Sebastian Huber wrote:
> Ping.

Which repo? Is this in the rtems-tools repo?

Please understand there is a limited number people reviewing and it takes time.
I am blocked on the other changes you have recently posted. Adding which hosts
you have built and tested this change on would help?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] 6: Use Binutils 2.41

[Chris Johns]

On 3/8/2023 5:37 pm, Sebastian Huber wrote:
> What about this patch and the GCC update to 13.2?

I have not tested it. Have you posted any build results to builds@rtems...?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libdebugger: Restrict ARM architecture support

[Chris Johns]

On 3/8/2023 10:17 pm, Sebastian Huber wrote:
> Build the arm libdebugger support only for supported ARM architectures.

What ARM archs are not supported?

> This fixes assembler errors at -O0.

How does it fix the assembler errors?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 2/8/2023 6:49 pm, Chris Johns wrote:
 > I am concerned about the compatibility to the ecosystem we have. Have you 
 > built
> all the tests in the testsuite with this value set to something that is not
> RTEMS default? I think a few things will break because of hard coding in them.

I have asked for test results and I have not seen any yet the patch has been
merged? The change was not approved my me and is still not approved.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RBW] Re: Tried and liked: Suntour Cyclone pretzel

[JohnS]

A project is always a good excuse for buying a new tool, as a friend of my 
use to say. May as well splurge on the alignment tool and see how it works 
out. Personally I'm suspicions of the elongated bolt hole, not sure why, 
but it doesn't look good. Any frame builders in a hour or two drive from 
you? If I were in your shoes I would take it to Bilenky Cycle Works 
<https://www.bilenky.com/> in Philly, I've heard good things about them and 
they always have great looking bikes at the Philly Bike Expo.

Good luck,
JohnS

On Wednesday, August 2, 2023 at 11:49:34 PM UTC-4 Ryan wrote:

> Your local shops sound like non-starters, if the one isn't confident and 
> the other is bad juju. Freighting the bike coast-to-coast and back  to Riv  
> + their labor   sounds like it's not a deal-breaker. Sounds like the west 
> coast is the mecca for framebuilders. I have no idea about the east coast 
> or mid-US. I wonder if you could get a second opinion from Mark 
> Nobilette...although I would not be surprised if he is retired or 
> contemplating retirement. 
>
>  I've bought 3 bikes from Riv2 customs and many parts and while the 
> wait time may be long, I would totally trust them to move heaven and earth 
> to get your bike right. If it means that much to you I would put myself in 
> their hands. You have that established  relationship with them. 
>
> My .002CAD...good luck. I'm sure you'll resolve this one way or another
>
> On Wednesday, August 2, 2023 at 10:21:49 PM UTC-5 Ryan wrote:
>
>> And sheep in your poster , if I recall correctly. Very bucolic
>>
>> I feel you  about the freight. Are there no reputable builders closer to 
>> you who could do the repair? In a neighbouring state perhaps?
>>
>> On Wednesday, August 2, 2023 at 10:03:10 PM UTC-5 eric...@gmail.com 
>> wrote:
>>
>>> Thanks, Ryan. Yes, I think the cost for the repair would be reasonable. 
>>> I worry the cost to freight the frame would be a little painful and the 
>>> time without the bike could be considerable depending on how it shakes out. 
>>>
>>> The poster is the MTB countryside illustration, same illustrator who did 
>>> yours. "Get away fast on a Bridgestone" or something like that. Hills, dirt 
>>> road, country church. 
>>>
>>> On Tuesday, August 1, 2023 at 7:36:10 AM UTC-4 Ryan wrote:
>>>
>>>> Yikes! That is too bad but I'm glad you weren't hurt. I know you are 
>>>> very ingenious, but maybe the frame needs to be sent to Riv for repair? 
>>>> Who 
>>>> will no doubt do the repair at a reasonable cost
>>>>
>>>> Which poster? I have the "saddle up on a bridgestone"...my favorite of 
>>>> the Grant-inspired ones...the one with the rider on a roadbike alongside a 
>>>> galloping horse. Can't remember if I bought it from Rivendell or from a 
>>>> friend of mine who built many of my wheels and at one time was a 
>>>> bridgestone dealer and sold me my 1993 X0-1 that I still have
>>>>
>>>> On Tuesday, August 1, 2023 at 4:55:39 AM UTC-5 R. Alexis wrote:
>>>>
>>>>> That does not look good. Maybe once you get it into a stand and 
>>>>> carefully remove the derailleur and gently realign the hanger you will be 
>>>>> fine. The rear der pully cage can probably be bent back into shape. Issue 
>>>>> is probably trusting it. Hope things work out. Glad you were not hurt. 
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Reginald Alexis
>>>>>
>>>>> On Sunday, July 23, 2023 at 2:13:02 PM UTC-5 eric...@gmail.com wrote:
>>>>>
>>>>>> Hey gang — I was out for a Sunday ride and stopped to take a picture. 
>>>>>> I rolled to the side of the road and did not see the culvert, hidden 
>>>>>> with 
>>>>>> fresh grass clippings. I tumbled over at low speed. I'm fine! 
>>>>>>
>>>>>> When I stood up I noticed my drive-side bar end shifter had rotated 
>>>>>> 90º. And my derailer hanger and the derailer were bent. I spun the crank 
>>>>>> while off the bike and it seemed to move okay so I thought I'd give it a 
>>>>>> go 
>>>>>> as a single speed. 
>>>>>>
>>>>>> I pedaled for a few strokes, then nudged the shifter. It was at that 
>>>>>> time the derailer turned upside down and inside out, bending into the 
>>>>>> spokes and throwing the chain. It was really fun!
>>>>>>
>>>>

Re: [PATCH rtems-tools v3] tester/rtemstoolkit: add renode implementation

[Chris Johns]

On 2/8/2023 8:08 pm, Muhammad Sulthan Mazaya wrote:
> Add licensing for renode files and change the renode_scripts/ folder to
> renode/

Where is the license for the .bin file? I only saw a link to the script used to
build it but it was not clear what the license is because it downloads Linux and
that is GPL.

What is the license?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 2/8/2023 6:56 pm, Sebastian Huber wrote:
> On 02.08.23 10:50, Chris Johns wrote:
>> On 2/8/2023 6:39 pm, Sebastian Huber wrote:
>>> On 02.08.23 10:33, Chris Johns wrote:
>>>>> diff --git a/spec/build/bsps/makeinc.yml b/spec/build/bsps/makeinc.yml
>>>>> index ac395f2f02..08fc75a8b9 100644
>>>>> --- a/spec/build/bsps/makeinc.yml
>>>>> +++ b/spec/build/bsps/makeinc.yml
>>>>> @@ -16,14 +16,14 @@ content: |
>>>>>  prefix = ${PREFIX}
>>>>>  exec_prefix = $${prefix}/${ARCH}-rtems${__RTEMS_MAJOR__}
>>>>>    -  CC_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc
>>>>> -  CXX_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
>>>>> -  AS_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-as
>>>>> -  AR_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
>>>>> -  NM_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-nm
>>>>> -  LD_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
>>>>> -  SIZE_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-size
>>>>> -  OBJCOPY_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
>>>>> +  CC_FOR_TARGET = ${PROGRAM_PREFIX}gcc
>>>>> +  CXX_FOR_TARGET = ${PROGRAM_PREFIX}g++
>>>> Is it worth doing the same to gcc and g++ as well so these can be replaced 
>>>> as
>>>> well?
>>> Yes, but this would be another patch and it is a bit more work since you 
>>> have to
>>> test the clang support.
>>>
>>>>> +  AS_FOR_TARGET = ${PROGRAM_PREFIX}as
>>>>> +  AR_FOR_TARGET = ${PROGRAM_PREFIX}ar
>>>>> +  NM_FOR_TARGET = ${PROGRAM_PREFIX}nm
>>>>> +  LD_FOR_TARGET = ${PROGRAM_PREFIX}ld
>>>>> +  SIZE_FOR_TARGET = ${PROGRAM_PREFIX}size
>>>>> +  OBJCOPY_FOR_TARGET = ${PROGRAM_PREFIX}objcopy
>>>> Where is PROGRAM_PFREFIX set?
>>> It is a new configuration option:
>>>
>>> [sparc/gr740]
>>> PROGRAM_PREFIX = ${ARCH}-rtems7-
>>>
>> Yes, but if these files are installed does it need to be in defined in those
>> files?
> 
> The option substitution takes place before the files are installed. For 
> example:

Ah OK. I did not pick that up in the patch.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 2/8/2023 6:39 pm, Sebastian Huber wrote:
> On 02.08.23 10:33, Chris Johns wrote:
>>> diff --git a/spec/build/bsps/makeinc.yml b/spec/build/bsps/makeinc.yml
>>> index ac395f2f02..08fc75a8b9 100644
>>> --- a/spec/build/bsps/makeinc.yml
>>> +++ b/spec/build/bsps/makeinc.yml
>>> @@ -16,14 +16,14 @@ content: |
>>>     prefix = ${PREFIX}
>>>     exec_prefix = $${prefix}/${ARCH}-rtems${__RTEMS_MAJOR__}
>>>   -  CC_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc
>>> -  CXX_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
>>> -  AS_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-as
>>> -  AR_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
>>> -  NM_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-nm
>>> -  LD_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
>>> -  SIZE_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-size
>>> -  OBJCOPY_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
>>> +  CC_FOR_TARGET = ${PROGRAM_PREFIX}gcc
>>> +  CXX_FOR_TARGET = ${PROGRAM_PREFIX}g++
>> Is it worth doing the same to gcc and g++ as well so these can be replaced as
>> well?
> 
> Yes, but this would be another patch and it is a bit more work since you have 
> to
> test the clang support.
> 
>>
>>> +  AS_FOR_TARGET = ${PROGRAM_PREFIX}as
>>> +  AR_FOR_TARGET = ${PROGRAM_PREFIX}ar
>>> +  NM_FOR_TARGET = ${PROGRAM_PREFIX}nm
>>> +  LD_FOR_TARGET = ${PROGRAM_PREFIX}ld
>>> +  SIZE_FOR_TARGET = ${PROGRAM_PREFIX}size
>>> +  OBJCOPY_FOR_TARGET = ${PROGRAM_PREFIX}objcopy
>> Where is PROGRAM_PFREFIX set?
> 
> It is a new configuration option:
> 
> [sparc/gr740]
> PROGRAM_PREFIX = ${ARCH}-rtems7-
> 

Yes, but if these files are installed does it need to be in defined in those 
files?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 2/8/2023 6:42 pm, Sebastian Huber wrote:
> On 02.08.23 10:40, Chris Johns wrote:
>> On 2/8/2023 6:33 pm, Chris Johns wrote:
>>> On 2/8/2023 3:49 pm, Sebastian Huber wrote:
>>>> Replace --rtems-version with a PROGRAM_PREFIX option.  This allows also
>>>> the use of vendor tools.> ---
>> One further thing to consider is if PROGRAM_PREFIX could clash with something
>> else in a user's environment because it is not in any RTEMS name space, ie
>> RTEMS_PROGRAM_PREFIX?
> 
> No, this could not clash. The options have their own namespace.

What about Makefile.inc when installed?

I am concerned about the compatibility to the ecosystem we have. Have you built
all the tests in the testsuite with this value set to something that is not
RTEMS default? I think a few things will break because of hard coding in them.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 2/8/2023 6:33 pm, Chris Johns wrote:
> On 2/8/2023 3:49 pm, Sebastian Huber wrote:
>> Replace --rtems-version with a PROGRAM_PREFIX option.  This allows also
>> the use of vendor tools.> ---

One further thing to consider is if PROGRAM_PREFIX could clash with something
else in a user's environment because it is not in any RTEMS name space, ie
RTEMS_PROGRAM_PREFIX?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 2/8/2023 3:49 pm, Sebastian Huber wrote:
> Replace --rtems-version with a PROGRAM_PREFIX option.  This allows also
> the use of vendor tools.> ---
>  spec/build/bsps/makeinc.yml| 16 
>  spec/build/bsps/maketarget.yml | 22 +++---
>  spec/build/bsps/optobjcopy.yml |  2 +-
>  spec/build/cpukit/cpuopts.yml  |  2 ++
>  spec/build/cpukit/optgcc.yml   |  8 
>  spec/build/cpukit/optprogramprefix.yml | 18 ++
>  spec/build/testsuites/ada/optgnat.yml  |  2 +-
>  wscript| 24 ++--
>  8 files changed, 47 insertions(+), 47 deletions(-)
>  create mode 100644 spec/build/cpukit/optprogramprefix.yml
> 
> diff --git a/spec/build/bsps/makeinc.yml b/spec/build/bsps/makeinc.yml
> index ac395f2f02..08fc75a8b9 100644
> --- a/spec/build/bsps/makeinc.yml
> +++ b/spec/build/bsps/makeinc.yml
> @@ -16,14 +16,14 @@ content: |
>prefix = ${PREFIX}
>exec_prefix = $${prefix}/${ARCH}-rtems${__RTEMS_MAJOR__}
>  
> -  CC_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc
> -  CXX_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
> -  AS_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-as
> -  AR_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
> -  NM_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-nm
> -  LD_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
> -  SIZE_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-size
> -  OBJCOPY_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
> +  CC_FOR_TARGET = ${PROGRAM_PREFIX}gcc
> +  CXX_FOR_TARGET = ${PROGRAM_PREFIX}g++

Is it worth doing the same to gcc and g++ as well so these can be replaced as 
well?

> +  AS_FOR_TARGET = ${PROGRAM_PREFIX}as
> +  AR_FOR_TARGET = ${PROGRAM_PREFIX}ar
> +  NM_FOR_TARGET = ${PROGRAM_PREFIX}nm
> +  LD_FOR_TARGET = ${PROGRAM_PREFIX}ld
> +  SIZE_FOR_TARGET = ${PROGRAM_PREFIX}size
> +  OBJCOPY_FOR_TARGET = ${PROGRAM_PREFIX}objcopy

Where is PROGRAM_PFREFIX set?

>CC= $$(CC_FOR_TARGET)
>CXX= $$(CXX_FOR_TARGET)
> diff --git a/spec/build/bsps/maketarget.yml b/spec/build/bsps/maketarget.yml
> index 798b64fa22..7a7b0c3d35 100644
> --- a/spec/build/bsps/maketarget.yml
> +++ b/spec/build/bsps/maketarget.yml
> @@ -11,17 +11,17 @@ content: |
>LIBS =
>  
>RTEMS_API = ${__RTEMS_MAJOR__}
> -  CC = ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc --pipe
> -  AS = ${ARCH}-rtems${__RTEMS_MAJOR__}-as
> -  AR = ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
> -  NM = ${ARCH}-rtems${__RTEMS_MAJOR__}-nm
> -  LD = ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
> -  SIZE = ${ARCH}-rtems${__RTEMS_MAJOR__}-size
> -  STRIP = ${ARCH}-rtems${__RTEMS_MAJOR__}-strip
> -  OBJCOPY = ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
> -  RANLIB = ${ARCH}-rtems${__RTEMS_MAJOR__}-ranlib
> -
> -  CXX = ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
> +  CC = ${PROGRAM_PREFIX}gcc --pipe
> +  AS = ${PROGRAM_PREFIX}as
> +  AR = ${PROGRAM_PREFIX}ar
> +  NM = ${PROGRAM_PREFIX}nm
> +  LD = ${PROGRAM_PREFIX}ld
> +  SIZE = ${PROGRAM_PREFIX}size
> +  STRIP = ${PROGRAM_PREFIX}strip
> +  OBJCOPY = ${PROGRAM_PREFIX}objcopy
> +  RANLIB = ${PROGRAM_PREFIX}ranlib
> +
> +  CXX = ${PROGRAM_PREFIX}g++

Same here with setting PROGRAM_PREFIX?

Chris

>  
>export CC
>export AS
> diff --git a/spec/build/bsps/optobjcopy.yml b/spec/build/bsps/optobjcopy.yml
> index 3387e23794..63fab08ac6 100644
> --- a/spec/build/bsps/optobjcopy.yml
> +++ b/spec/build/bsps/optobjcopy.yml
> @@ -1,6 +1,6 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  actions:
> -- set-value: ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
> +- set-value: ${PROGRAM_PREFIX}objcopy
>  - substitute: null
>  - find-program: null
>  - env-assign: OBJCOPY
> diff --git a/spec/build/cpukit/cpuopts.yml b/spec/build/cpukit/cpuopts.yml
> index f1b30eec55..1d28ace552 100644
> --- a/spec/build/cpukit/cpuopts.yml
> +++ b/spec/build/cpukit/cpuopts.yml
> @@ -7,6 +7,8 @@ guard: _RTEMS_SCORE_CPUOPTS_H
>  include-headers: []
>  install-path: ${BSP_INCLUDEDIR}/rtems/score
>  links:
> +- role: build-dependency
> +  uid: optprogramprefix
>  - role: build-dependency
>uid: optgcc
>  - role: build-dependency
> diff --git a/spec/build/cpukit/optgcc.yml b/spec/build/cpukit/optgcc.yml
> index 3afb909444..94af494af4 100644
> --- a/spec/build/cpukit/optgcc.yml
> +++ b/spec/build/cpukit/optgcc.yml
> @@ -1,21 +1,21 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  actions:
> -- set-value: ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc
> +- set-value: ${PROGRAM_PREFIX}gcc
>  - substitute: null
>  - find-program: null
>  - env-assign: AS
>  - env-assign: CC
>  - env-assign: LINK_CC
> -- set-value: ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
> +- set-value: ${PROGRAM_PREFIX}g++
>  - substitute: null
>  - find-program: null
>  - env-assign: CXX
>  - env-assign: LINK_CXX
> -- set-value: ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
> +- set-value: ${PROGRAM_PREFIX}ar
>  - substitute: null
>  - find-program: null
>  - env-assign: AR
> -- set-value: ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
> +- 

Re: [PATCH] build: Optionally use a VERSION file

[Chris Johns]

On 2/8/2023 2:46 pm, Sebastian Huber wrote:
> On 02.08.23 06:01, Chris Johns wrote:
>>> Allow the command line
>>> option --rtems-version to override __RTEMS_MAJOR__.  Remove support for
>>> command line configurable options.
>> I do not understand this last bit. It says allow --rtems-version and then the
>> command line configuration options are removed? And my reading of the change 
>> the
>> command line support has been removed?
> 
> The patch removes the --rtems-option command line support. The --rtems-version
> is needed to build for example using the RTEMS 7 tools.

Ah of course. Thanks.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Optionally use a VERSION file

[Chris Johns]

On 1/8/2023 5:11 pm, Sebastian Huber wrote:
> Define the RTEMS version in the wscript.  Optionally use a VERSION file
> to change the default values of the wscript. 

Thanks, this is welcome. I will update the release scripts when merged.

> Allow the command line
> option --rtems-version to override __RTEMS_MAJOR__.  Remove support for
> command line configurable options.

I do not understand this last bit. It says allow --rtems-version and then the
command line configuration options are removed? And my reading of the change the
command line support has been removed?

> Rename internal define RTEMS_VERSION_VC_KEY to
> RTEMS_VERSION_CONTROL_KEY.

OK.

Thanks
Chris

> ---
>  cpukit/sapi/src/version.c   |   8 +--
>  spec/build/cpukit/cpuopts.yml   |   6 --
>  spec/build/cpukit/optvermaj.yml |  13 
>  spec/build/cpukit/optvermin.yml |  13 
>  spec/build/cpukit/optverrev.yml |  13 
>  wscript | 108 +++-
>  6 files changed, 55 insertions(+), 106 deletions(-)
>  delete mode 100644 spec/build/cpukit/optvermaj.yml
>  delete mode 100644 spec/build/cpukit/optvermin.yml
>  delete mode 100644 spec/build/cpukit/optverrev.yml
> 
> diff --git a/cpukit/sapi/src/version.c b/cpukit/sapi/src/version.c
> index ea07683876..7197ddd153 100644
> --- a/cpukit/sapi/src/version.c
> +++ b/cpukit/sapi/src/version.c
> @@ -54,8 +54,8 @@
>  
>  const char *rtems_version( void )
>  {
> -#ifdef RTEMS_VERSION_VC_KEY
> -  return RTEMS_VERSION "." RTEMS_VERSION_VC_KEY;
> +#ifdef RTEMS_VERSION_CONTROL_KEY
> +  return RTEMS_VERSION "." RTEMS_VERSION_CONTROL_KEY;
>  #else
>return RTEMS_VERSION;
>  #endif
> @@ -78,8 +78,8 @@ int rtems_version_revision( void )
>  
>  const char *rtems_version_control_key( void )
>  {
> -#ifdef RTEMS_VERSION_VC_KEY
> -  return RTEMS_VERSION_VC_KEY;
> +#ifdef RTEMS_VERSION_CONTROL_KEY
> +  return RTEMS_VERSION_CONTROL_KEY;
>  #else
>return "";
>  #endif
> diff --git a/spec/build/cpukit/cpuopts.yml b/spec/build/cpukit/cpuopts.yml
> index 49dfc26e4b..f1b30eec55 100644
> --- a/spec/build/cpukit/cpuopts.yml
> +++ b/spec/build/cpukit/cpuopts.yml
> @@ -7,12 +7,6 @@ guard: _RTEMS_SCORE_CPUOPTS_H
>  include-headers: []
>  install-path: ${BSP_INCLUDEDIR}/rtems/score
>  links:
> -- role: build-dependency
> -  uid: optvermaj
> -- role: build-dependency
> -  uid: optvermin
> -- role: build-dependency
> -  uid: optverrev
>  - role: build-dependency
>uid: optgcc
>  - role: build-dependency
> diff --git a/spec/build/cpukit/optvermaj.yml b/spec/build/cpukit/optvermaj.yml
> deleted file mode 100644
> index e194930b47..00
> --- a/spec/build/cpukit/optvermaj.yml
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> -actions:
> -- get-string-command-line: '6'
> -- env-assign: null
> -build-type: option
> -copyrights:
> -- Copyright (C) 2020 embedded brains GmbH & Co. KG
> -default: []
> -description: ''
> -enabled-by: true
> -links: []
> -name: __RTEMS_MAJOR__
> -type: build
> diff --git a/spec/build/cpukit/optvermin.yml b/spec/build/cpukit/optvermin.yml
> deleted file mode 100644
> index 8a58959394..00
> --- a/spec/build/cpukit/optvermin.yml
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> -actions:
> -- set-value: '0'
> -- env-assign: null
> -build-type: option
> -copyrights:
> -- Copyright (C) 2020 embedded brains GmbH & Co. KG
> -default: []
> -description: ''
> -enabled-by: true
> -links: []
> -name: __RTEMS_MINOR__
> -type: build
> diff --git a/spec/build/cpukit/optverrev.yml b/spec/build/cpukit/optverrev.yml
> deleted file mode 100644
> index 618c936e86..00
> --- a/spec/build/cpukit/optverrev.yml
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> -actions:
> -- set-value: '0'
> -- env-assign: null
> -build-type: option
> -copyrights:
> -- Copyright (C) 2020 embedded brains GmbH & Co. KG
> -default: []
> -description: ''
> -enabled-by: true
> -links: []
> -name: __RTEMS_REVISION__
> -type: build
> diff --git a/wscript b/wscript
> index 862000513d..13c1d1d4d9 100755
> --- a/wscript
> +++ b/wscript
> @@ -43,7 +43,13 @@ except:
>  from waflib.TaskGen import after, before_method, feature
>  
>  is_windows_host = os.name == "nt" or sys.platform in ["msys", "cygwin"]
> -default_prefix = "/opt/rtems/6"
> +version = {
> +"__RTEMS_MAJOR__": "6",
> +"__RTEMS_MINOR__": "0",
> +"__RTEMS_REVISION__": "0",
> +"RTEMS_VERSION_CONTROL_KEY": "git"
> +}
> +default_prefix = "/opt/rtems/" + version["__RTEMS_MAJOR__"]
>  compilers = ["gcc", "clang"]
>  items = {}
>  bsps = {}
> @@ -62,22 +68,28 @@ class VersionControlKeyHeader:
>  
>  @staticmethod
>  def write(bld, filename):
> -if VersionControlKeyHeader._content is None:
> -from waflib.Build import Context
> -from waflib.Errors import WafError
> -
> +content = VersionControlKeyHeader._content
> +if 

Re: [PATCH RTEMS] spec: Remove empty reset from mvme3100

[Chris Johns]

OK

Thanks
Chris

On 2/8/2023 6:16 am, Vijay Kumar Banerjee wrote:
> ---
>  spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml 
> b/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
> index 1667c1617a..fbb85123f0 100644
> --- a/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
> +++ b/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
> @@ -86,6 +86,5 @@ source:
>  - bsps/shared/dev/getentropy/getentropy-cpucounter.c
>  - bsps/shared/dev/rtc/rtc-support.c
>  - bsps/shared/start/bspfatal-default.c
> -- bsps/shared/start/bspreset-empty.c
>  - bsps/shared/start/gettargethash-default.c
>  type: build
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: MicroBlaze Dynamic Loader Test Failures

[Chris Johns]

On 1/8/2023 1:46 pm, Alex White wrote:
> Hi,
> 
> I am currently working on RTEMS dynamic loader support for MicroBlaze. I got 
> most of the dynamic loader tests working, but for a few of them, I had to 
> modify the test. I believe the failures are because the MicroBlaze RTEMS port 
> uses soft floating point emulation. Tests dl07, dl08, and dl09 fail because 
> the objects being loaded include floating point code that requires an extra 
> routine from GCC, `__extendsfdf2`, that is not included in the base 
> application.
> 
> According to GCC documentation 
> (https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html), 
> `__extendsfdf2` is used to extend a float to a double. This is needed in test 
> dl07, for example, to print `dl01_bss2[0]` on line 66:
> 
> printf (DL_NAME ": dl01_bss2: %4zu: %p: %f\n", PAINT_VAR (dl01_bss2[0]));
> 
> The modification that I made to get this working was to add the following to 
> init.c in each of the three failing tests:
> 
> #ifdef __microblaze__
> extern double __extendsfdf2 (float a);
> /* This ensures that __extendsfdf2 is included in the compiled output. */
> double (*extendsfdf2_fp)(float) = &__extendsfdf2;
> #endif /* __microblaze__ */
> 
> I'm not sure of any way to check whether or not this code should be included 
> other than `#ifdef __microblaze__`. This doesn't seem like a great solution, 
> though. I searched for a predefined macro that would allow this to be generic 
> across different architectures, maybe something indicating software floating 
> point, but I couldn't find anything suitable.
> 
> Does anyone have a suggestion for a better way to solve this?

There is no clean way to solve this. It is the classic embedded dynamic loading
trade off normally solved at a system level.

A solution that may work is to add `libgcc.a` to the tar file in the test exe
then configure a `/etc/ld.conf` (I think that is the file name) to search the
archive for symbols. The RTL should resolve the missing symbols on the target at
run time and load the needed object files.

If this support is made conditional on some sort of soft-float build system
conditional it should work for any other targets with the same issue.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

[Chris Johns]

On 31/7/2023 5:14 pm, Sebastian Huber wrote:
> On 29.07.23 08:30, Chris Johns wrote:
>>> I think this is not really related to the new
>>> RTEMS_VERSION_VC_KEY/RTEMS_VERSION_CONTROL_KEY option. The purpose of this
>>> option is to give users the ability to define their own version control key.
>>
>> I think we are broadly aligned however there are different labels for some 
>> the
>> pieces [1]. I have reviewed the existing code and then this change and it
>> seems the default is an empty string a user can altered via a config.ini 
>> file.
>> Is this correct?
> 
> In v2 of the patch, the default is "git" indicating that the version control 
> key
> should be obtained using Git.

What version control keys are supported?

>>
>> Is this per BSP or global?
> 
> This is per BSP. All the configuration options are per BSP. In your config.ini
> you can set options for all BSPs via the [DEFAULT] section.

Per BSP does not make sense. Having a means for a user to inject anything at
build time is confusing to me because it can be different for the same set of
sources.

>> For me the sources are the controlled item the calls rtems_version() and
>> rtems_version_control_key() should report and not what a user can configure.
> 
> We don't control the version control system of the user, so it should be user
> configurable.

The configuration file controls a build and this setting changes the meaning of
the configuration data being built. It does not align.

>> Why not just look for a file called VERSION and then a key=value pair that 
>> is:
>>
>> RTEMS_VERSION_VC_KEY=foo-bar
> 
> Why not just use what is normally used by the build system? Supporting the
> VERSION file needs extra code for only one purpose.

Yes releasing RTEMS. At the moment a get clone of a release tag will show a file
does not match. In a formal sense that would require a special consideration
that would need to be documented and applied.

> I think naming this option RTEMS_VERSION_CONTROL_KEY makes more sense, since 
> the
> corresponding RTEMS API directive is rtems_version_control_key(). Is VC a well
> known abbreviation?

The name in the API is what it is and I am not suggesting it be changed. Maybe
it could have been more general to serve a wider purpose than just the VC but it
is there now so that time has passed.

>>
>> And document deployment users add this file and then configuration control 
>> the
>> released sources and this file?
> 
> The config.ini are not included in the sources shipped with RTEMS and they can
> be version controlled by the user.

That is the central point I am attempting to make. Version data should be the
version of the sources shipped and not the build.

A build label is different and would clearly state the purpose and if I see a
bug report I can ignore it and concentrate on the version data.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RBW] Re: ISO Roadini...or?

[JohnS]

Very nice ride Jamin, thanks for sharing.

JohnS

On Sunday, July 30, 2023 at 10:55:58 AM UTC-4 jamin orrall wrote:

> Keep an eye out for an 80's specialized sequoia, they are wonderful bikes. 
>  Fits 32's or 650b's with tektro r559s, rides like a fast Rivendell but a 
> little flexier. One of my favorite bikes.
> [image: IMG_6651.JPG]
> On Saturday, July 29, 2023 at 8:08:18 AM UTC-4 Bones wrote:
>
>> Thanks! The saddle height in that picture is probably between 79-80.
>>
>> Bones
>>
>> On Friday, July 28, 2023 at 12:55:05 PM UTC-4 jhri...@gmail.com wrote:
>>
>>> Bones, that's a beautiful Roadini build. Could I ask your saddle height? 
>>> I'm 78.5ish with an 89.5 PBH and having a difficult time deciding between 
>>> frames myself.
>>>
>>> On Friday, July 21, 2023 at 1:46:37 PM UTC-4 JohnS wrote:
>>>
>>>> Hello Peter,
>>>>
>>>> Wow, an '81 Sequoia! Those are very rare since only about 700 were made 
>>>> by hand. In '82 is when production ramped up. Please post a picture if you 
>>>> can.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>> On Friday, July 21, 2023 at 11:58:26 AM UTC-4 eric...@gmail.com wrote:
>>>>
>>>>> Very nice build, Bones!  B) 
>>>>>
>>>>> On Friday, July 21, 2023 at 11:05:30 AM UTC-4 Bones wrote:
>>>>>
>>>>>> I started with an Appaloosa, which I built as a workhorse to ferry my 
>>>>>> kids around. I wanted something without all the racks and utility so I 
>>>>>> purchased a Hillborne. Great bike, but I found it too similar to my 
>>>>>> Appaloosa so I moved it along and bought a Roadini. It was exactly what 
>>>>>> I 
>>>>>> was looking for. No, it is not a delicate, lightweight bike. That is to 
>>>>>> my 
>>>>>> benefit, as I can do stupid things to it without worrying about it being 
>>>>>> damaged. It is a Rivendell, and it rides like all of my other 
>>>>>> Rivendells. 
>>>>>> It currently resides at my parents' house, and I make a point to ride it 
>>>>>> whenever I visit. I love that bike.
>>>>>>
>>>>>> [image: roadini2.jpg]
>>>>>>
>>>>>> Bones
>>>>>>
>>>>>> On Friday, July 21, 2023 at 1:49:48 AM UTC-4 chasenl...@gmail.com 
>>>>>> wrote:
>>>>>>
>>>>>>> [image: IMG_4997.jpeg]
>>>>>>>
>>>>>>> I am about 200 miles into my orange-ass roadini and I love it. Set 
>>>>>>> up with a23s, dirt drops, cavas and an analog 30mm stem. It is not 
>>>>>>> flexy 
>>>>>>> and light like my rb 2. It is no sports car. Its like a benz, smooth 
>>>>>>> and 
>>>>>>> comfy. I have a 90 stumpjumper (that I’m convinced could be the worlds 
>>>>>>> greatest bicycle), and the roadini is v similar, minus canti post, add 
>>>>>>> practical geometry. It is definitely stout, which makes the lack of 
>>>>>>> rack 
>>>>>>> mounts annoying, but its not t stout. To me, it feels like a road 
>>>>>>> tourer, not a zippy speed machine. I think a crust mallochio or 
>>>>>>> lightning 
>>>>>>> bolt might be lighter/flexier/zippier. 
>>>>>>> On Wednesday, July 19, 2023 at 10:03:16 PM UTC-4 Doug H. wrote:
>>>>>>>
>>>>>>>> This paragraph is from Will's recent email... If this sounds like 
>>>>>>>> what you're looking for then I say buy one. 
>>>>>>>>
>>>>>>>> "Yes, the Roadini is heavier than a carbon frame, but, and even 
>>>>>>>> though it's a cliche phrase at this point, *it rides light* and I 
>>>>>>>> don't care if I'm two minutes slower than my alternate-universe self 
>>>>>>>> who 
>>>>>>>> rides a carbon bike. I still feel fast on it, and I'm not racing 
>>>>>>>> anybody 
>>>>>>>> anyway, even myself. My bike priorities are safety, comfort, 
>>>>>>>> reliability, 
>>>>>>>> and the ability to stretch the bike beyond it's stated purpose. Most 
>>>>>>>> of you 
>>>>>>>

Re: [PATCH rtems-tools v2] tester/rtemstoolkit: add renode implementation

[Chris Johns]

On 31/7/2023 11:24 am, Muhammad Sulthan Mazaya wrote:
> Hi Chris,
> 
>> This file does not look like a script to me. I suggest removing _scripts from
> the path
> 
> Sure, I will revise it
> 
>> What is this file and where did it come from? I see no attribution or sources
> to make this binary file?
> 
> It's leon3's prom image, the source I use to build the binary is from this
> repository 
> https://github.com/antmicro/renode-rtems-leon3/blob/main/build-prom.sh 
> . 
> About the attribution, where should I add it?
> 

I think a README-leon3-prom.txt with the details is a start.

The script you linked is specific to Linux, with things like `/bin/bash`, 
`pushd`.

Can the RTEMS tools be used to build the PROM?

What is the license for it?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools v2] tester/rtemstoolkit: add renode implementation

[Chris Johns]

On 29/7/2023 12:08 pm, Muhammad Sulthan Mazaya wrote:
> Add leon3 implementation for rtems-test using renode.
> 
> ---
>  .../testing/bsps/kendrytek210-renode.ini  |  38 ++
>  tester/rtems/testing/bsps/leon3-renode.ini|  37 ++
>  tester/rtems/testing/renode.cfg   |  65 ++
>  .../testing/renode_scripts/kendrytek210.resc  |  53 ++
>  .../testing/renode_scripts/leon3-prom.bin | Bin 0 -> 529 bytes
>  .../rtems/testing/renode_scripts/leon3.resc   |  47 +
>  6 files changed, 240 insertions(+)
>  create mode 100644 tester/rtems/testing/bsps/kendrytek210-renode.ini
>  create mode 100644 tester/rtems/testing/bsps/leon3-renode.ini
>  create mode 100644 tester/rtems/testing/renode.cfg
>  create mode 100644 tester/rtems/testing/renode_scripts/kendrytek210.resc
>  create mode 100755 tester/rtems/testing/renode_scripts/leon3-prom.bin

This file does not look like a script to me. I suggest removing _scripts from
the path, eg:

 tester/rtems/testing/renode/leon3-prom.bin

What is this file and where did it come from? I see no attribution or sources to
make this binary file?

Chris

>  create mode 100644 tester/rtems/testing/renode_scripts/leon3.resc
> 
> diff --git a/tester/rtems/testing/bsps/kendrytek210-renode.ini 
> b/tester/rtems/testing/bsps/kendrytek210-renode.ini
> new file mode 100644
> index 000..95850c5
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/kendrytek210-renode.ini
> @@ -0,0 +1,38 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2010-2014 Chris Johns (chr...@rtems.org)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are met:
> +#
> +# 1. Redistributions of source code must retain the above copyright notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright 
> notice,
> +# this list of conditions and the following disclaimer in the documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> +# POSSIBILITY OF SUCH DAMAGE.
> +#
> +
> +#
> +# The Kendrytek210 Renode BSP
> +#
> +[kendrytek210-renode]
> +bsp = kendrytek210-renode
> +arch= riscv
> +tester  = %{_rtscripts}/renode.cfg
> +bsp_resc_script = %{_rtscripts}/renode_scripts/kendrytek210.resc
> diff --git a/tester/rtems/testing/bsps/leon3-renode.ini 
> b/tester/rtems/testing/bsps/leon3-renode.ini
> new file mode 100644
> index 000..af48043
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/leon3-renode.ini
> @@ -0,0 +1,37 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2010-2014 Chris Johns (chr...@rtems.org)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are met:
> +# # 1. Redistributions of source code must retain the above copyright notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright 
> notice,
> +# this list of conditions and the following disclaimer in the documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> 

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

[Chris Johns]

On 28/7/2023 6:26 pm, Sebastian Huber wrote:

On 28.07.23 07:37, Chris Johns wrote:

On 27/7/2023 3:59 pm, Sebastian Huber wrote:

On 27.07.23 06:36, Chris Johns wrote:


On 26/7/2023 4:54 pm, Sebastian Huber wrote:

On 26.07.23 08:20, Chris Johns wrote:

On 26/7/2023 3:44 pm, Sebastian Huber wrote:

On 26.07.23 06:58, Sebastian Huber wrote:

On 26.07.23 00:08, Chris Johns wrote:

On 26/7/2023 4:27 am, Joel Sherrill wrote:

On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>>
wrote:

    On 25.07.23 19:09, Joel Sherrill wrote:
    >
    > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
    > mailto:sebastian.hu...@embedded-brains.de>
    > <mailto:sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>>> wrote:
    >
    >     Allow the user to set the version control key.
    >     ---
    >       spec/build/cpukit/grp.yml             |  2 ++
    >       spec/build/cpukit/optversionvckey.yml | 20 
++

    >       wscript                               | 38
---
    >       3 files changed, 44 insertions(+), 16 
deletions(-)
    >       create mode 100644 
spec/build/cpukit/optversionvckey.yml

    >
    >     diff --git a/spec/build/cpukit/grp.yml
b/spec/build/cpukit/grp.yml
    >     index e07e975d7d..fbeab45b5c 100644
    >     --- a/spec/build/cpukit/grp.yml
    >     +++ b/spec/build/cpukit/grp.yml
    >     @@ -18,6 +18,8 @@ links:
    >         uid: cpuopts
    >       - role: build-dependency
    >         uid: cfghdr
    >     +- role: build-dependency
    >     +  uid: optversionvckey
    >       - role: build-dependency
    >         uid: libdebugger
    >       - role: build-dependency
    >     diff --git a/spec/build/cpukit/optversionvckey.yml
    >     b/spec/build/cpukit/optversionvckey.yml
    >     new file mode 100644
    >     index 00..7197381342
    >     --- /dev/null
    >     +++ b/spec/build/cpukit/optversionvckey.yml
    >     @@ -0,0 +1,20 @@
    >     +SPDX-License-Identifier: CC-BY-SA-4.0 OR 
BSD-2-Clause

    >     +actions:
    >     +- get-string: null
    >     +- env-assign: null
    >     +build-type: option
    >     +copyrights:
    >     +- Copyright (C) 2022, 2023 embedded brains GmbH 
& Co. KG

    >     +default:
    >     +- enabled-by: true
    >     +  value: ''
    >     +description: |
    >     +  If defined to a non-empty value, then the 
value will be

used for
    >     the version
    >     +  control key returned by rtems_version() and
    >     rtems_version_control_key(),
    >     +  otherwise the value will be determined by the 
Git

repository
    >     containing the
    >     +  waf top directory.
    >
    >
    > And would this change for a release tarball?

    Which RTEMS_VERSION_VC_KEY has a release tarball? What 
happens if

you
    unpack an release archive in an external Git repository?


I don't know but think we should discuss it.

Chris should speak up since the release scripts are his and this
might be used by the distribution packaging he has made 
available.
I am not sure what the purpose of this change is. It would be 
good to

understand
what it is for. The RTEMS_VERSION_VC_KEY could mean a number of 
things such

as a
means to set the git hash in sources not in a git repo but that 
is guess.
Yes, this is helpful if you have the RTEMS sources not in a Git 
repository or

the Git repository has the wrong commit (git subtree for example).

It could be also useful for the release archive. We could use 
this scheme:


* If the value is "git", then get the value from git.

* If the value is "", then we use no version key.

* Otherwise we set the key to the value.

For the release archive we would set the default value of the 
option from

"git" to "".

I sent a patch with this approach:

https://lists.rtems.org/pipermail/devel/2023-July/075989.html
Can you please just explain the mechanics of how this gets used? 
While I could

try and guess but I would rather not. 

In the v2 patch you just have to do this for a release archive:

sed -i "s/  value: git/  value: ''/" 
spec/build/cpukit/optversioncontrolkey.yml



Does this mean the default is changed in the sources in the tarball?


Yes, this is one option.



Can the option be overridden in a config file?


This depends on what we want. If you just change the default value, 
then you can

change it in your config.ini. It will also show up in

./waf bspdefaults --rtems-bsps sparc/erc32| grep 

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

[Chris Johns]

On 27/7/2023 3:59 pm, Sebastian Huber wrote:
> On 27.07.23 06:36, Chris Johns wrote:
>>
>> On 26/7/2023 4:54 pm, Sebastian Huber wrote:
>>> On 26.07.23 08:20, Chris Johns wrote:
>>>> On 26/7/2023 3:44 pm, Sebastian Huber wrote:
>>>>> On 26.07.23 06:58, Sebastian Huber wrote:
>>>>>> On 26.07.23 00:08, Chris Johns wrote:
>>>>>>> On 26/7/2023 4:27 am, Joel Sherrill wrote:
>>>>>>>> On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber
>>>>>>>> >>>>>>> <mailto:sebastian.hu...@embedded-brains.de>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>    On 25.07.23 19:09, Joel Sherrill wrote:
>>>>>>>>    >
>>>>>>>>    > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
>>>>>>>>    > >>>>>>> <mailto:sebastian.hu...@embedded-brains.de>
>>>>>>>>    > <mailto:sebastian.hu...@embedded-brains.de
>>>>>>>> <mailto:sebastian.hu...@embedded-brains.de>>> wrote:
>>>>>>>>    >
>>>>>>>>    >     Allow the user to set the version control key.
>>>>>>>>    >     ---
>>>>>>>>    >       spec/build/cpukit/grp.yml             |  2 ++
>>>>>>>>    >       spec/build/cpukit/optversionvckey.yml | 20 
>>>>>>>> ++
>>>>>>>>    >       wscript                               | 38
>>>>>>>> ---
>>>>>>>>    >       3 files changed, 44 insertions(+), 16 deletions(-)
>>>>>>>>    >       create mode 100644 spec/build/cpukit/optversionvckey.yml
>>>>>>>>    >
>>>>>>>>    >     diff --git a/spec/build/cpukit/grp.yml
>>>>>>>> b/spec/build/cpukit/grp.yml
>>>>>>>>    >     index e07e975d7d..fbeab45b5c 100644
>>>>>>>>    >     --- a/spec/build/cpukit/grp.yml
>>>>>>>>    >     +++ b/spec/build/cpukit/grp.yml
>>>>>>>>    >     @@ -18,6 +18,8 @@ links:
>>>>>>>>    >         uid: cpuopts
>>>>>>>>    >       - role: build-dependency
>>>>>>>>    >         uid: cfghdr
>>>>>>>>    >     +- role: build-dependency
>>>>>>>>    >     +  uid: optversionvckey
>>>>>>>>    >       - role: build-dependency
>>>>>>>>    >         uid: libdebugger
>>>>>>>>    >       - role: build-dependency
>>>>>>>>    >     diff --git a/spec/build/cpukit/optversionvckey.yml
>>>>>>>>    >     b/spec/build/cpukit/optversionvckey.yml
>>>>>>>>    >     new file mode 100644
>>>>>>>>    >     index 00..7197381342
>>>>>>>>    >     --- /dev/null
>>>>>>>>    >     +++ b/spec/build/cpukit/optversionvckey.yml
>>>>>>>>    >     @@ -0,0 +1,20 @@
>>>>>>>>    >     +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>>>>>>>>    >     +actions:
>>>>>>>>    >     +- get-string: null
>>>>>>>>    >     +- env-assign: null
>>>>>>>>    >     +build-type: option
>>>>>>>>    >     +copyrights:
>>>>>>>>    >     +- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
>>>>>>>>    >     +default:
>>>>>>>>    >     +- enabled-by: true
>>>>>>>>    >     +  value: ''
>>>>>>>>    >     +description: |
>>>>>>>>    >     +  If defined to a non-empty value, then the value will be
>>>>>>>> used for
>>>>>>>>    >     the version
>>>>>>>>    >     +  control key returned by rtems_version() and
>>>>>>>>    >     rtems_version_control_key(),
>>>>>>>>    >     +  otherwise the value will be determ

Re: No RTEMS documentation updates on the web site?

[Chris Johns]

On 27/7/2023 4:30 pm, Sebastian Huber wrote:
> Hello,
> 
> it seems the RTEMS documentation on the web site is from 24th of January:
> 
> https://docs.rtems.org/
> 

Yeah. I was waiting for the updates to service2.rtems.org to be done before
sorting it out but that work was delayed because of the move to gitlab. If the
original work pack was done at the time it would have required service2 being
reworked again, ie twice, and that would have resulted in even higher costs.
That was 4 or 5 months ago.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Pushing to 6.1

[Chris Johns]

On 28/7/2023 5:28 am, Joel Sherrill wrote:
> On Thu, Jul 27, 2023, 2:14 PM Karel Gardas  wrote:
> 
>    Hello,
> 
> do we have any plan with timeline? I think to see some roadmap would be
> greatly appreciated on all sides, wouldn't it?
> 
> People starting asking me this about two years ago. Everytime I have given a
> time, it has been ignored and blown threw. :(

That is a little unfair. The issues from back then may still exist and will
continue to exist until resolved. Someone in the end has to do the work and for
RTEMS 5 it all came down to me, with some extra help, to clean up and fill in
the gaps.

> I know you want to get your STM work in. Just try to wrap it up sooner than 
> later. 
> 
> I know we need to address some issues for the EPICS community but creeping
> featuritis is killing us. 
> 
> Perfection is the enemy of good enough.

This is unhelpful. The best way to get things moving is to take a ticket that is
outstanding and produce fixes. There are some regressions we cannot ignore.

I will consider starting the release process once I am sure the servers are
sorted or being sorted and the release can be made cleanly with suitable space.
The server work started 6 months ago and I have been waiting at least 3 or 4
months for this to continue. Here is the link
https://devel.rtems.org/wiki/FundingProjects.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RBW] Tried and liked: Suntour Cyclone pretzel

[JohnS]

Grant steps up again and delivered the goods! I would love to see their 
parts stash, box o' frame parts here, forks over there

JohnS 

On Wednesday, July 26, 2023 at 9:28:40 PM UTC-4 Wesley wrote:

> Possibly dumb question: have you taken a good look at your chain? It ay be 
> kinked, which would cause skipping gears.
> -Wes
>
> On Wednesday, July 26, 2023 at 4:04:01 PM UTC-7 eric...@gmail.com wrote:
>
>> Andre attempted to make some further adjustments, the chain still skips. 
>> I tried installing a Deore XT M771 and that was a little bit better but the 
>> chain still skips. 
>>
>> I called Riv and talked to Grant who was eager to see some pictures. Will 
>> has a new dropout heading to me by mail, now I just need to find someone 
>> who can braze the new dropout on. The framebuilder I know has transitioned 
>> from building bikes to chartering boats! 
>>
>> On Tuesday, July 25, 2023 at 8:43:30 PM UTC-4 Eric Marth wrote:
>>
>>> Yesterday I brought the frame to my LBS, Bike Works and handed it over 
>>> to trusted mechanic Andre. He bent the hanger, aligned the dropouts and 
>>> aligned the hanger. The hanger alignment tool showed the hanger was in 
>>> plane with the rim. Amazingly the hole took a derailer bolt just fine. It 
>>> looks terrible but functionality seemed promising. This was all I cared 
>>> about.
>>>
>>> You can see the hole is terribly elongated. 
>>>
>>> [image: IMG_6872.JPG] 
>>>
>>> [image: IMG_6871.JPG]
>>>
>>> Here's my wavy hanger.
>>>
>>> [image: IMG_6880.JPG]
>>>
>>> Fortunately I have a small collection of Cyclones to draw from. The last 
>>> one I mangled was beautiful old stock. This one here is almost as nice. 
>>>
>>> The bike shifted fine in the stand. But on the road and under load the 
>>> chain skips in the smallest four cogs. 
>>>
>>> Tomorrow I'll take it back to Andre and see if he can't finesse it into 
>>> shape. 
>>> On Tuesday, July 25, 2023 at 8:38:04 PM UTC-4 Eric Marth wrote:
>>>
>>>> Patrick: Sorry about that Fargo but glad to hear it could be repaired. 
>>>> Replaceable hangers seem helpful!
>>>>
>>>> On Monday, July 24, 2023 at 10:41:41 AM UTC-4 Patrick Moore wrote:
>>>>
>>>>> And: I had Chauncey Matthews use a replaceable hanger when he built 
>>>>> the replacement for the Fargo.
>>>>>
>>>>> On Mon, Jul 24, 2023 at 8:38 AM Patrick Moore  
>>>>> wrote:
>>>>>
>>>>>> FWIW, I had a similar experience with a Fargo when a stick jammed the 
>>>>>> rd: the hangar was bent 90* inward (and jammed into the cassette; no 
>>>>>> single-speeding home). The good news, and the point: a LBS was able to 
>>>>>> unbend the rd to usable status again. The replacement rd worked fine. Of 
>>>>>> course, YMMV.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 24, 2023 at 7:50 AM Eric Marth  wrote:
>>>>>>
>>>>>>> Many thanks, John. I'll check out the spokes. 
>>>>>>>
>>>>>>> I've been texting with my local mechanic friend, Andre. We're going 
>>>>>>> to try and bend the hanger and see how close we can get it. Considering 
>>>>>>> a 
>>>>>>> drop out saver from Wheels Mfg. 
>>>>>>>
>>>>>>> If that fails I'll see about having a new dropout installed. I gotta 
>>>>>>> call Will when Riv opens!
>>>>>>>
>>>>>>> On Monday, July 24, 2023 at 8:36:56 AM UTC-4 JohnS wrote:
>>>>>>>
>>>>>>>> Wow Eric, that was a bad one, glad your ok and the Sam is on the 
>>>>>>>> mend. Don't forget to check the spokes for nicks, could break easy if 
>>>>>>>> they 
>>>>>>>> are.
>>>>>>>>
>>>>>>>> JohnS
>>>>>>>>
>>>>>>>>
>>>>>>>> On Monday, July 24, 2023 at 7:54:06 AM UTC-4 Josh C wrote:
>>>>>>>>
>>>>>>>>> Wow. That's wild. Glad you're ok. Bummer about the Sam, that's a 
>>>>>>>>> beautiful bike.
>>>>>>>>>
>>>>>>>>> On Sunday, July 23, 2023 at 9:08:55 PM UTC-4 eric...@gmail.com 

Re: [RBW] Re: Early 80's Specialized Sequoia

[JohnS]

Hello Erik,

Nice looking Sequoia! I agree, my '82 has a nice ride feel to it as well. I 
did a 60 mile ride this past Saturday on it, very comfortable, fits very 
well. You can check the year of your bike by looking at the serial number 
stamped on the bottom bracket. Mine starts with M2, indicating 1982, so I 
would think you bike would be M6.

JohnS

On Wednesday, July 26, 2023 at 11:01:55 PM UTC-4 Stephen wrote:

> Hey Erik!
>
> Fun to see that old sequoia pop up on here, still got a soft spot in my 
> heart for that bike! Good memories..
>
> Cheers,
>
> Stephen
>
> On Wednesday, July 26, 2023 at 2:04:33 PM UTC-4 Ted Durant wrote:
>
>> On Monday, July 24, 2023 at 11:09:06 PM UTC-4 John Dewey wrote:
>>
>> Just so y’all know, TD is kind of a local legend. He is, after all, one 
>> of Richard Schwinn’s best pals.
>>
>>
>> Anyone who read Grant's Blahg entry on the closing of Waterford will know 
>> that Richard Schwinn has more best pals than just about anyone you can 
>> name. I happen to be lucky enough to live near him and his true best pal, 
>> his wife, Shoe. And I get to see them regularly at Milwaukee Symphony 
>> Orchestra concerts.
>>
>> Regarding my Waterford  keep your eyes out for the next issue of 
>> American Randonneur.
>>
>>  Ted Durant
>> Milwaukee WI USA
>>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/c515c329-77ac-4e76-a892-4b211f4d6c26n%40googlegroups.com.

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

[Chris Johns]

On 26/7/2023 4:54 pm, Sebastian Huber wrote:
> On 26.07.23 08:20, Chris Johns wrote:
>> On 26/7/2023 3:44 pm, Sebastian Huber wrote:
>>> On 26.07.23 06:58, Sebastian Huber wrote:
>>>> On 26.07.23 00:08, Chris Johns wrote:
>>>>> On 26/7/2023 4:27 am, Joel Sherrill wrote:
>>>>>> On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber
>>>>>> >>>>> <mailto:sebastian.hu...@embedded-brains.de>>
>>>>>> wrote:
>>>>>>
>>>>>>   On 25.07.23 19:09, Joel Sherrill wrote:
>>>>>>   >
>>>>>>   > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
>>>>>>   > >>>>> <mailto:sebastian.hu...@embedded-brains.de>
>>>>>>   > <mailto:sebastian.hu...@embedded-brains.de
>>>>>> <mailto:sebastian.hu...@embedded-brains.de>>> wrote:
>>>>>>   >
>>>>>>   >     Allow the user to set the version control key.
>>>>>>   >     ---
>>>>>>   >       spec/build/cpukit/grp.yml             |  2 ++
>>>>>>   >       spec/build/cpukit/optversionvckey.yml | 20 ++
>>>>>>   >       wscript                               | 38
>>>>>> ---
>>>>>>   >       3 files changed, 44 insertions(+), 16 deletions(-)
>>>>>>   >       create mode 100644 spec/build/cpukit/optversionvckey.yml
>>>>>>   >
>>>>>>   >     diff --git a/spec/build/cpukit/grp.yml
>>>>>> b/spec/build/cpukit/grp.yml
>>>>>>   >     index e07e975d7d..fbeab45b5c 100644
>>>>>>   >     --- a/spec/build/cpukit/grp.yml
>>>>>>   >     +++ b/spec/build/cpukit/grp.yml
>>>>>>   >     @@ -18,6 +18,8 @@ links:
>>>>>>   >         uid: cpuopts
>>>>>>   >       - role: build-dependency
>>>>>>   >         uid: cfghdr
>>>>>>   >     +- role: build-dependency
>>>>>>   >     +  uid: optversionvckey
>>>>>>   >       - role: build-dependency
>>>>>>   >         uid: libdebugger
>>>>>>   >       - role: build-dependency
>>>>>>   >     diff --git a/spec/build/cpukit/optversionvckey.yml
>>>>>>   >     b/spec/build/cpukit/optversionvckey.yml
>>>>>>   >     new file mode 100644
>>>>>>   >     index 00..7197381342
>>>>>>   >     --- /dev/null
>>>>>>   >     +++ b/spec/build/cpukit/optversionvckey.yml
>>>>>>   >     @@ -0,0 +1,20 @@
>>>>>>   >     +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>>>>>>   >     +actions:
>>>>>>   >     +- get-string: null
>>>>>>   >     +- env-assign: null
>>>>>>   >     +build-type: option
>>>>>>   >     +copyrights:
>>>>>>   >     +- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
>>>>>>   >     +default:
>>>>>>   >     +- enabled-by: true
>>>>>>   >     +  value: ''
>>>>>>   >     +description: |
>>>>>>   >     +  If defined to a non-empty value, then the value will be
>>>>>> used for
>>>>>>   >     the version
>>>>>>   >     +  control key returned by rtems_version() and
>>>>>>   >     rtems_version_control_key(),
>>>>>>   >     +  otherwise the value will be determined by the Git 
>>>>>> repository
>>>>>>   >     containing the
>>>>>>   >     +  waf top directory.
>>>>>>   >
>>>>>>   >
>>>>>>   > And would this change for a release tarball?
>>>>>>
>>>>>>   Which RTEMS_VERSION_VC_KEY has a release tarball? What happens if 
>>>>>> you
>>>>>>   unpack an release archive in an external Git repository?
>>>>>>
>>>>>>
>>>>>> I don't know but think we should discuss it.
>>>>>>
>>

Re: [PATCH] doxygen: Replace main page

[Chris Johns]

On 26/7/2023 3:50 pm, Sebastian Huber wrote:
> Replace the main page with a high level description of the RTEMS feature
> set similar to:
> 
> https://docs.rtems.org/branches/master/user/overview/index.html#features
> 
> The replaced content can be found in the RTEMS Classic API Guide:
> 

This makes sense.

> + * The Real-Time Executive for Multiprocessor Systems (RTEMS) is a
> + * multi-threaded, single address-space, real-time operating system with no
> + * kernel-space/user-space separation.  It is capable to operate in an SMP
> + * configuration providing a state of the art feature set.
> + *
> + * RTEMS is licensed under a [modified GPL 2.0 or later license with an
> + * exception for static linking](https://git.rtems.org/rtems/tree/LICENSE>).
> + * It exposes no license requirements on application code.  The third-party
> + * software used and distributed by RTEMS which may be linked to the
> + * application is licensed under permissive open source licenses.  Everything
> + * necessary to build RTEMS applications is available as open source 
> software.
> + * This makes you completely vendor independent.
> + *
> + * The goal is to use the [BSD 2-Clause
> + * license](https://git.rtems.org/rtems/tree/LICENSE.BSD-2-Clause) for new 
> code
> + * or code those copyright holder agreed to a license change, see
> + * [#3053](https://devel.rtems.org/ticket/3053) for the details.

Why all this detail about the licenses here?

I think it complicates things by adding another place it is mentioned. A list of
licences or a comment on how to determine the licenses yes.

I would have though we are now mostly BSD with some places still GLP+exception.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

[Chris Johns]

On 26/7/2023 3:44 pm, Sebastian Huber wrote:
> On 26.07.23 06:58, Sebastian Huber wrote:
>> On 26.07.23 00:08, Chris Johns wrote:
>>> On 26/7/2023 4:27 am, Joel Sherrill wrote:
>>>> On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber
>>>> >>> <mailto:sebastian.hu...@embedded-brains.de>>
>>>> wrote:
>>>>
>>>>  On 25.07.23 19:09, Joel Sherrill wrote:
>>>>  >
>>>>  > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
>>>>  > >>> <mailto:sebastian.hu...@embedded-brains.de>
>>>>  > <mailto:sebastian.hu...@embedded-brains.de
>>>> <mailto:sebastian.hu...@embedded-brains.de>>> wrote:
>>>>  >
>>>>  >     Allow the user to set the version control key.
>>>>  >     ---
>>>>  >       spec/build/cpukit/grp.yml             |  2 ++
>>>>  >       spec/build/cpukit/optversionvckey.yml | 20 ++
>>>>  >       wscript                               | 38
>>>> ---
>>>>  >       3 files changed, 44 insertions(+), 16 deletions(-)
>>>>  >       create mode 100644 spec/build/cpukit/optversionvckey.yml
>>>>  >
>>>>  >     diff --git a/spec/build/cpukit/grp.yml 
>>>> b/spec/build/cpukit/grp.yml
>>>>  >     index e07e975d7d..fbeab45b5c 100644
>>>>  >     --- a/spec/build/cpukit/grp.yml
>>>>  >     +++ b/spec/build/cpukit/grp.yml
>>>>  >     @@ -18,6 +18,8 @@ links:
>>>>  >         uid: cpuopts
>>>>  >       - role: build-dependency
>>>>  >         uid: cfghdr
>>>>  >     +- role: build-dependency
>>>>  >     +  uid: optversionvckey
>>>>  >       - role: build-dependency
>>>>  >         uid: libdebugger
>>>>  >       - role: build-dependency
>>>>  >     diff --git a/spec/build/cpukit/optversionvckey.yml
>>>>  >     b/spec/build/cpukit/optversionvckey.yml
>>>>  >     new file mode 100644
>>>>  >     index 00..7197381342
>>>>  >     --- /dev/null
>>>>  >     +++ b/spec/build/cpukit/optversionvckey.yml
>>>>  >     @@ -0,0 +1,20 @@
>>>>  >     +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>>>>  >     +actions:
>>>>  >     +- get-string: null
>>>>  >     +- env-assign: null
>>>>  >     +build-type: option
>>>>  >     +copyrights:
>>>>  >     +- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
>>>>  >     +default:
>>>>  >     +- enabled-by: true
>>>>  >     +  value: ''
>>>>  >     +description: |
>>>>  >     +  If defined to a non-empty value, then the value will be used 
>>>> for
>>>>  >     the version
>>>>  >     +  control key returned by rtems_version() and
>>>>  >     rtems_version_control_key(),
>>>>  >     +  otherwise the value will be determined by the Git repository
>>>>  >     containing the
>>>>  >     +  waf top directory.
>>>>  >
>>>>  >
>>>>  > And would this change for a release tarball?
>>>>
>>>>  Which RTEMS_VERSION_VC_KEY has a release tarball? What happens if you
>>>>  unpack an release archive in an external Git repository?
>>>>
>>>>
>>>> I don't know but think we should discuss it.
>>>>
>>>> Chris should speak up since the release scripts are his and this
>>>> might be used by the distribution packaging he has made available.
>>> I am not sure what the purpose of this change is. It would be good to 
>>> understand
>>> what it is for. The RTEMS_VERSION_VC_KEY could mean a number of things such 
>>> as a
>>> means to set the git hash in sources not in a git repo but that is guess.
>>
>> Yes, this is helpful if you have the RTEMS sources not in a Git repository or
>> the Git repository has the wrong commit (git subtree for example).
>>
>> It could be also useful for the release archive. We could use this scheme:
>>
>> * If the value is "git", then get the value from git.
>>
>> * If the value is "", then we use no version key.
>>
>> * Otherwise we set the key to the value.
>>
>> For the release archive we would set the default value of the option from
>> "git" to "".
> 
> I sent a patch with this approach:
> 
> https://lists.rtems.org/pipermail/devel/2023-July/075989.html

Can you please just explain the mechanics of how this gets used? While I could
try and guess but I would rather not. :)

We have an established method in other repos of adding a VERSION file to the
source tarball. Why not follow that method?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

[Chris Johns]

On 26/7/2023 4:27 am, Joel Sherrill wrote:
> On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber
>  >
> wrote:
> 
> On 25.07.23 19:09, Joel Sherrill wrote:
> >
> > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
> >  
> >  >> wrote:
> >
> >     Allow the user to set the version control key.
> >     ---
> >       spec/build/cpukit/grp.yml             |  2 ++
> >       spec/build/cpukit/optversionvckey.yml | 20 ++
> >       wscript                               | 38 
> ---
> >       3 files changed, 44 insertions(+), 16 deletions(-)
> >       create mode 100644 spec/build/cpukit/optversionvckey.yml
> >
> >     diff --git a/spec/build/cpukit/grp.yml b/spec/build/cpukit/grp.yml
> >     index e07e975d7d..fbeab45b5c 100644
> >     --- a/spec/build/cpukit/grp.yml
> >     +++ b/spec/build/cpukit/grp.yml
> >     @@ -18,6 +18,8 @@ links:
> >         uid: cpuopts
> >       - role: build-dependency
> >         uid: cfghdr
> >     +- role: build-dependency
> >     +  uid: optversionvckey
> >       - role: build-dependency
> >         uid: libdebugger
> >       - role: build-dependency
> >     diff --git a/spec/build/cpukit/optversionvckey.yml
> >     b/spec/build/cpukit/optversionvckey.yml
> >     new file mode 100644
> >     index 00..7197381342
> >     --- /dev/null
> >     +++ b/spec/build/cpukit/optversionvckey.yml
> >     @@ -0,0 +1,20 @@
> >     +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> >     +actions:
> >     +- get-string: null
> >     +- env-assign: null
> >     +build-type: option
> >     +copyrights:
> >     +- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
> >     +default:
> >     +- enabled-by: true
> >     +  value: ''
> >     +description: |
> >     +  If defined to a non-empty value, then the value will be used for
> >     the version
> >     +  control key returned by rtems_version() and
> >     rtems_version_control_key(),
> >     +  otherwise the value will be determined by the Git repository
> >     containing the
> >     +  waf top directory.
> >
> >
> > And would this change for a release tarball?
> 
> Which RTEMS_VERSION_VC_KEY has a release tarball? What happens if you
> unpack an release archive in an external Git repository?
> 
> 
> I don't know but think we should discuss it. 
> 
> Chris should speak up since the release scripts are his and this 
> might be used by the distribution packaging he has made available.

I am not sure what the purpose of this change is. It would be good to understand
what it is for. The RTEMS_VERSION_VC_KEY could mean a number of things such as a
means to set the git hash in sources not in a git repo but that is guess.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs 0/2] Sphinx Version Check

[Chris Johns]

Looks good.

Thanks
Chris

On 26/7/2023 6:25 am, Joel Sherrill wrote:
> Hi
> 
> There has been Discord and email discussion that upgrading to Sphinx >=
> 6.0 breaks unordered bullet lists. But using Sphinx < 6.0 does not
> produce correct results with the patch which enabled us to use newer
> versions of Sphinx. There are two patches in this series.
> 
> (1) Reverts the patch which broke document generation. Hopefully this
> can be reapplied once someone with time and more Sphinx knowledge than I
> have figures out what is actually broken.
> 
> (2) Enhances the Sphinx version check to be able to check for a version
> greater than a minimum (current behavior) or if the Sphinx version is
> within an acceptable range. The acceptable min/max versions are set at
> the top of the file.
> 
> I think these are simple patches to unwedge documentation generation
> until a solution allowing us to upgrade is figured out. Then the minimum
> can be changed to 6.0 and maximum to None.
> 
> OK to commit?
> 
> --joel
> 
> Joel Sherrill (2):
>   layout.html: Revert patch forcing Spinx to >= 6.0
>   common/waf.py: Add option to check maximum Sphinx version
> 
>  common/sphinx_rtd_theme_rtems/layout.html |  2 --
>  common/waf.py | 17 ++---
>  2 files changed, 14 insertions(+), 5 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: style patches - discuss

[Chris Johns]

On 26/7/2023 7:41 am, Gedare Bloom wrote:
> I have sent two initial patches to begin the style reformat. The
> clang-format file is not quite 100%, and it's also not usable by
> anyone else (as I wait for changes to be accepted upstream).
> 
> A few things to note:
> * We can always manually override style with good reason. If you see
> something like that in a patch, please let me know.
> * I have started to avoid changing the __asm __ ... blocks, as
> clang-format doesn't do a great job with those at the moment.
> * clang-format also doesn't know how to indent broken if/for loops
> like we prefer. So i may need to continue manual intervention on those
> until I can get around to teaching it how. I believe that is doable,
> but will take me some time to implement and get upstream.
> * clang-format also has a preference to break function declarations
> differently than we do. It will prefer to break after the function
> return type/decorators, rather than in the parameter list. This may be
> something we can tune. For now, I fix this manually.
> 
> I may prepare a few more patches tomorrow, but I will leave these two
> for the time being for feedback.

Is there a branch in a repo I can look at to see the files with the style 
applied?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RBW] Re: Early 80's Specialized Sequoia

[JohnS]

Yep, Costner rode a red Allez in American Flyers, fun bike movie. I'll have 
to torture my family and watch it again some time. 

JohnS

On Tuesday, July 25, 2023 at 7:58:34 AM UTC-4 Ryan wrote:

> My bad...screwed up the colors. Anyway, I do remember being impressed by 
> how thoughtfully these bikes were designed and equipped, and the fact that 
> your 82 Sequoia (and no doubt 83 Expedition) is still going strong is a 
> testament to that.
>
> Other fun fact...I think the team bike on *American Flyers *starring 
> Kevin Costner was a Specialized Allez ; red, I think
>
> On Monday, July 24, 2023 at 1:59:57 PM UTC-5 JohnS wrote:
>
>> The early 80's Sequoia was the sport/touring model, in the middle between 
>> the road race Allez and the full on touring Expedition. Not sure what color 
>> options were available. I use to own an 83 Expedition in gray/anthracite. 
>> My 82 Sequoia is dark blue. It's not a feather weight, nor is it a tank, 
>> weigh in at just over 23 pounds with pedals and two water bottle cages. 
>> Fully lugged Tange chrome-moly tubing, with long thinned lugs, it has nice 
>> neutral handling, mounts for fenders and a rear rack and room for 32mm 
>> tires (maybe 35).
>>
>> JohnS
>>
>> On Monday, July 24, 2023 at 1:12:35 PM UTC-4 Ryan wrote:
>>
>>> I also suspect they varied tubing sets basis frame size ; something that 
>>> Bridgestones also did , if you read their ad copy
>>>
>>> On Monday, July 24, 2023 at 12:04:43 PM UTC-5 Ryan wrote:
>>>
>>>> I remember *Bicycle Guide* praising those Sequoias for their fine ride 
>>>> and careful craftsmanship, but they pointed out that the bikes weren't 
>>>> particularly light. Sport-touring? I also remember Specialized having a 
>>>> full-bore touring bike with all required the braze-ons for fenders/racks 
>>>> 3- 
>>>> water bottle braze-ons called the Expedition, appropriately and I seem to 
>>>> recall in *Bicycling *ads that these were dark blue. Maybe that's what 
>>>> your friend toured on?
>>>>
>>>> On Monday, July 24, 2023 at 10:44:15 AM UTC-5 iamkeith wrote:
>>>>
>>>>> Were there different versions of the Sequoia?  The one I was familiar 
>>>>> with was a dark metalic grey one, but I think it came in dark blue, too.  
>>>>> It wA a fantastic bike, built by Toyo if I remember correctly. But I 
>>>>> thought it was a full-on touring bike, with heavy tubing, low bottom 
>>>>> bracket  shallow seat tub angle - compared to sportier bikes of the era.  
>>>>> My friend used his for numerous, long, heavily-loaded tours, including a 
>>>>> months-long, dirt-road (mud) trek from Montana to Alaska and back.
>>>>>
>>>>> On Saturday, July 22, 2023 at 11:31:13 AM UTC-6 Ted Durant wrote:
>>>>>
>>>>>> On Saturday, July 22, 2023 at 11:57:41 AM UTC-4 Peter Bridge wrote:
>>>>>>
>>>>>> Did your noticeably heavy Sequoia perhaps have heavy wheels or 
>>>>>> thornproof tubes or a spring Brooks saddle or some such?  I find 
>>>>>> Sequoias 
>>>>>> to be sportingly light. 
>>>>>>
>>>>>> No, it was the stock parts that came with it. Fairly light wheels, 
>>>>>> Turbo tires. I would make the same statement about Heron #1, the 
>>>>>> prototype, 
>>>>>> which is a Road frame built with Touring stays at the rear. Both frames 
>>>>>> are 
>>>>>> a joy to ride. 
>>>>>>
>>>>>> Interestingly, I read somewhere that the Sequoia was designed with a 
>>>>>> bit heavier down tube and chain stays. Recently I posted on a frame 
>>>>>> building forum a query about the ratio of stiffness among the frame 
>>>>>> tubes. 
>>>>>> If you look at older Reynolds tube set specs, they have .1mm thicker 
>>>>>> down 
>>>>>> tubes than top and seat. Or, if you like, their top and seat tube walls 
>>>>>> are 
>>>>>> .1mm thinner than the down tube. All other tube manufacturers, and even 
>>>>>> Reynolds now today, specify tube sets with equal wall thickness around 
>>>>>> the 
>>>>>> main triangle. It's also important to note that the down tube and seat 
>>>>>> tube 
>>>>>> were always 1/8" larger diameter than the top tube. Lately it seems 
>>>>>>

Re: [PATCH] score: Add workaround for GCC bug

[Chris Johns]

OK

Chris

On 25/7/2023 4:04 pm, Sebastian Huber wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
> 
> This GCC bug leads to an incomplete code coverage status.
> 
> Update #4932.
> ---
>  cpukit/score/cpu/no_cpu/cpuidle.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/cpukit/score/cpu/no_cpu/cpuidle.c 
> b/cpukit/score/cpu/no_cpu/cpuidle.c
> index bff1309d39..a6001e73b0 100644
> --- a/cpukit/score/cpu/no_cpu/cpuidle.c
> +++ b/cpukit/score/cpu/no_cpu/cpuidle.c
> @@ -33,6 +33,13 @@
>  
>  void *_CPU_Thread_Idle_body( uintptr_t ignored )
>  {
> +  /*
> +   * This is a workaround for:
> +   *
> +   * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
> +   */
> +  __asm__ volatile ("");
> +
>while ( true ) {
>  /* Do nothing */
>}
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] 6: Use GDB 13.2

[Chris Johns]

On 25/7/2023 3:18 pm, Sebastian Huber wrote:
> On 25.07.23 03:43, Chris Johns wrote:
>> On 24/7/2023 9:53 pm, Sebastian Huber wrote:
>>> Hello Karel,
>>>
>>> On 24.07.23 13:15, Karel Gardas wrote:
>>>>
>>>> this together with also libexpat patch builds fine on:
>>>>
>>>> - macOS 13.4.1
>>>> - FreeBSD 13.2
>>>> - Ubuntu 20.04
>>>
>>> thanks for the testing.
>>>
>>>>
>>>> btw, recently Joel remarked that gdb from 7/ makes troubles building on 
>>>> fbsd
>>>> 12.x. I verified the same on fbsd 13.x and Hesham noted on discord that he 
>>>> has
>>>> the same issues on macOS. GBD from 7/rtems-* complains about missing 
>>>> libmpfr.
>>>>
>>>> [...]
>>>> checking for the correct version of gmp.h... yes
>>>> checking for the correct version of mpfr.h... no
>>>> configure: error: Building GDB requires GMP 4.2+, and MPFR 3.1.0+.
>>>> Try the --with-gmp and/or --with-mpfr options to specify
>>>> their locations.  If you obtained GMP and/or MPFR from a vendor
>>>> distribution package, make sure that you have installed both the libraries
>>>> and the header files.  They may be located in separate packages.
>>>> shell cmd failed: /bin/sh -ex
>>>> /usr/home/karel/git/rtems-source-builder/rtems/build/aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1/do-build
>>>> error: building aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1
>>>>
>>>> Obviusly gdb from 6/ does not hence there is probably some bit missing in 
>>>> 7/
>>>> which is already fixed in 6/
>>>
>>> Actually I don't know how this should be handled. Some libraries are added 
>>> to
>>> rtems/config/6/rtems-default.bset others seem to be specific tool files. 
>>> The 7/
>>> tools should a minimum set of patches. Things should be directly fixed in 
>>> the
>>> upstream projects.
>>
>> We have been moving to build support libraries, such as GMP, separately and 
>> not
>> by links into the source tree of gcc. MacOS M silicon requires a specific 
>> option
>> for GMP to work and this has resulted in us building these libraries before
>> building the packages that depend on them because the upstream provide no 
>> means
>> to inject specific options. GDB added GMP and it seems more are being added 
>> so
>> we need to add support to build them before GDB and remove the symlink'ing 
>> into
>> the GCC source tree. The GMP change should provide a suitable template for 
>> doing
>> this.
> 
> So, ISL, MPC, MPFR, etc. should also move to the top level configuration?

We have been doing this as required, ie more than one package depends on it or
extra options. I suppose it is OK to build them them all from the top level. It
would protect us later if we find we need to handle the package in a specific
way, eg many years from now.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] 6: Use GDB 13.2

[Chris Johns]

On 24/7/2023 9:53 pm, Sebastian Huber wrote:
> Hello Karel,
> 
> On 24.07.23 13:15, Karel Gardas wrote:
>>
>> this together with also libexpat patch builds fine on:
>>
>> - macOS 13.4.1
>> - FreeBSD 13.2
>> - Ubuntu 20.04
> 
> thanks for the testing.
> 
>>
>> btw, recently Joel remarked that gdb from 7/ makes troubles building on fbsd
>> 12.x. I verified the same on fbsd 13.x and Hesham noted on discord that he 
>> has
>> the same issues on macOS. GBD from 7/rtems-* complains about missing libmpfr.
>>
>> [...]
>> checking for the correct version of gmp.h... yes
>> checking for the correct version of mpfr.h... no
>> configure: error: Building GDB requires GMP 4.2+, and MPFR 3.1.0+.
>> Try the --with-gmp and/or --with-mpfr options to specify
>> their locations.  If you obtained GMP and/or MPFR from a vendor
>> distribution package, make sure that you have installed both the libraries
>> and the header files.  They may be located in separate packages.
>> shell cmd failed: /bin/sh -ex
>> /usr/home/karel/git/rtems-source-builder/rtems/build/aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1/do-build
>> error: building aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1
>>
>> Obviusly gdb from 6/ does not hence there is probably some bit missing in 7/
>> which is already fixed in 6/
> 
> Actually I don't know how this should be handled. Some libraries are added to
> rtems/config/6/rtems-default.bset others seem to be specific tool files. The 
> 7/
> tools should a minimum set of patches. Things should be directly fixed in the
> upstream projects.

We have been moving to build support libraries, such as GMP, separately and not
by links into the source tree of gcc. MacOS M silicon requires a specific option
for GMP to work and this has resulted in us building these libraries before
building the packages that depend on them because the upstream provide no means
to inject specific options. GDB added GMP and it seems more are being added so
we need to add support to build them before GDB and remove the symlink'ing into
the GCC source tree. The GMP change should provide a suitable template for doing
this.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/arm: fix installation broken by recent CMSIS files update

[Chris Johns]

Hi Karel,

I did not see this and made and pushed a similar patch. Thanks for this and
sorry for not checking closely as I missed it on the first pass.

Thanks
Chris

On 25/7/2023 1:53 am, Karel Gardas wrote:
> ---
>  spec/build/bsps/arm/grp.yml | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml
> index 1058f58d92..a48cd80d74 100644
> --- a/spec/build/bsps/arm/grp.yml
> +++ b/spec/build/bsps/arm/grp.yml
> @@ -10,12 +10,13 @@ includes: []
>  install:
>  - destination: ${BSP_INCLUDEDIR}
>source:
> +  - bsps/arm/include/cachel1_armv7.h
> +  - bsps/arm/include/cmsis_compiler.h
>- bsps/arm/include/cmsis_gcc.h
> +  - bsps/arm/include/cmsis_version.h
>- bsps/arm/include/core_cm7.h
>- bsps/arm/include/core_cm4.h
> -  - bsps/arm/include/core_cmFunc.h
> -  - bsps/arm/include/core_cmInstr.h
> -  - bsps/arm/include/core_cmSimd.h
> +  - bsps/arm/include/mpu_armv7.h
>- bsps/arm/include/uart.h
>  - destination: ${BSP_INCLUDEDIR}/bsp
>source:
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RBW] DIY Nitto rack hoop

[JohnS]

Thanks for sharing Jay! I'll have to remember that combination of daruma 
and p-clamps, very creative solution. Looks great to me.

JohnS

On Monday, July 24, 2023 at 2:21:51 PM UTC-4 Dustin wrote:

> Jay, 
>
> Nice tombstone!  Not “kludgy” at all. Thanks for sharing 
>
> Dustin 
>
> On Jul 20, 2023, at 11:05 PM, Jay Lonner  wrote:
>
> For those interested, here’s what I came up with. Bending an aluminum 
> rack stay with an improvised mandrel was easy. Two p-clamps and two daruma 
> fixtures rounded out the hardware, and the installation doesn’t even look 
> all that kludgy. Fits the leather pocket on my SaddleSack like a glove. 
> Pics attached, with bonus glimpses of my wife’s Cheviot in the background.
>
> Jay Lonner
> Bellingham, WA
>
> 
> 
>
> 
>
>
> Sent from my Atari 400
>
> On Jul 12, 2023, at 11:02 AM, Jay Lonner  wrote:
>
> One of the downsides of the Big Back Rack is that it doesn’t come with 
> the tombstone/backstop feature that hooks so nicely into the leather patch 
> designed for that purpose on my large SaddlesSack. I’m thinking of making 
> one myself using daruma fixtures and a rack stay bent to fit. Does anybody 
> have experience with this sort of fabrication? Can you get a nice radius 
> bend with a bench vise and a soup can, or do you need a tubing bender? 
> Alternatively — and this is a long shot — if anybody has an old or damaged 
> rack with this feature, I’d be interested in buying it and trying my hand 
> at a tombstone transplant.
>
> Jay Lonner
> Bellingham, WA
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rbw-owners-bun...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/rbw-owners-bunch/25f31e6b-7856-4d80-9206-92bc2f0d02b5n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/rbw-owners-bunch/25f31e6b-7856-4d80-9206-92bc2f0d02b5n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rbw-owners-bun...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/rbw-owners-bunch/24472E28-67DA-4590-B1FB-53A4E6D8CF3E%40gmail.com
>  
> <https://groups.google.com/d/msgid/rbw-owners-bunch/24472E28-67DA-4590-B1FB-53A4E6D8CF3E%40gmail.com?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/fe121ea2-28e6-4963-b251-e44a6115b0d1n%40googlegroups.com.

[RBW] Re: Early 80's Specialized Sequoia

[JohnS]

The early 80's Sequoia was the sport/touring model, in the middle between 
the road race Allez and the full on touring Expedition. Not sure what color 
options were available. I use to own an 83 Expedition in gray/anthracite. 
My 82 Sequoia is dark blue. It's not a feather weight, nor is it a tank, 
weigh in at just over 23 pounds with pedals and two water bottle cages. 
Fully lugged Tange chrome-moly tubing, with long thinned lugs, it has nice 
neutral handling, mounts for fenders and a rear rack and room for 32mm 
tires (maybe 35).

JohnS

On Monday, July 24, 2023 at 1:12:35 PM UTC-4 Ryan wrote:

> I also suspect they varied tubing sets basis frame size ; something that 
> Bridgestones also did , if you read their ad copy
>
> On Monday, July 24, 2023 at 12:04:43 PM UTC-5 Ryan wrote:
>
>> I remember *Bicycle Guide* praising those Sequoias for their fine ride 
>> and careful craftsmanship, but they pointed out that the bikes weren't 
>> particularly light. Sport-touring? I also remember Specialized having a 
>> full-bore touring bike with all required the braze-ons for fenders/racks 3- 
>> water bottle braze-ons called the Expedition, appropriately and I seem to 
>> recall in *Bicycling *ads that these were dark blue. Maybe that's what 
>> your friend toured on?
>>
>> On Monday, July 24, 2023 at 10:44:15 AM UTC-5 iamkeith wrote:
>>
>>> Were there different versions of the Sequoia?  The one I was familiar 
>>> with was a dark metalic grey one, but I think it came in dark blue, too.  
>>> It wA a fantastic bike, built by Toyo if I remember correctly. But I 
>>> thought it was a full-on touring bike, with heavy tubing, low bottom 
>>> bracket  shallow seat tub angle - compared to sportier bikes of the era.  
>>> My friend used his for numerous, long, heavily-loaded tours, including a 
>>> months-long, dirt-road (mud) trek from Montana to Alaska and back.
>>>
>>> On Saturday, July 22, 2023 at 11:31:13 AM UTC-6 Ted Durant wrote:
>>>
>>>> On Saturday, July 22, 2023 at 11:57:41 AM UTC-4 Peter Bridge wrote:
>>>>
>>>> Did your noticeably heavy Sequoia perhaps have heavy wheels or 
>>>> thornproof tubes or a spring Brooks saddle or some such?  I find Sequoias 
>>>> to be sportingly light. 
>>>>
>>>> No, it was the stock parts that came with it. Fairly light wheels, 
>>>> Turbo tires. I would make the same statement about Heron #1, the 
>>>> prototype, 
>>>> which is a Road frame built with Touring stays at the rear. Both frames 
>>>> are 
>>>> a joy to ride. 
>>>>
>>>> Interestingly, I read somewhere that the Sequoia was designed with a 
>>>> bit heavier down tube and chain stays. Recently I posted on a frame 
>>>> building forum a query about the ratio of stiffness among the frame tubes. 
>>>> If you look at older Reynolds tube set specs, they have .1mm thicker down 
>>>> tubes than top and seat. Or, if you like, their top and seat tube walls 
>>>> are 
>>>> .1mm thinner than the down tube. All other tube manufacturers, and even 
>>>> Reynolds now today, specify tube sets with equal wall thickness around the 
>>>> main triangle. It's also important to note that the down tube and seat 
>>>> tube 
>>>> were always 1/8" larger diameter than the top tube. Lately it seems steel 
>>>> builders have been experimenting away from that, but I haven't seen any 
>>>> discussion of why they would do that. For my Rivendell Road, for example, 
>>>> Grant spec'd the exact same tube for both top and down tubes. So, that 
>>>> goes 
>>>> the other direction, making the top tube exactly the same stiffness as the 
>>>> down tube. BUT, because the top tube is shorter than the down tube, there 
>>>> is less butted section remaining in the top tube. Anyway, my hypothesis is 
>>>> that the relative stiffness among the tubes has an effect on how the frame 
>>>> feels, and the a stiffer down tube and chain stays is what produced the 
>>>> "magic" feel of a Reynolds frame. Perhaps backing up this hypothesis is 
>>>> the 
>>>> "Spine" line of frames that Trek built, with steel or titanium down tubes 
>>>> and chain stays, and carbon tubes elsewhere. Their marketing touted the 
>>>> effect that had on the feel of the frame. A friend has the titanium one 
>>>> and 
>>>> he loves it.
>>>>
>>>> Sorry for the meandering detour. I just found the Specialized Sequoia 
>>>> frame to feel heavy when lifting, compared to some other steel frames. But 
>>>> I loved the way it rode.
>>>>
>>>> Ted Durant
>>>> Milwaukee WI USA
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/569039f9-576b-4d40-8b23-50b72316a306n%40googlegroups.com.

Re: [RBW] Tried and liked: Suntour Cyclone pretzel

[JohnS]

Wow Eric, that was a bad one, glad your ok and the Sam is on the mend. 
Don't forget to check the spokes for nicks, could break easy if they are.

JohnS


On Monday, July 24, 2023 at 7:54:06 AM UTC-4 Josh C wrote:

> Wow. That's wild. Glad you're ok. Bummer about the Sam, that's a beautiful 
> bike.
>
> On Sunday, July 23, 2023 at 9:08:55 PM UTC-4 eric...@gmail.com wrote:
>
>> Thanks Brian and Danny! 
>>
>> I got the mech freed. The parallelogram housing is twisted, too. The 
>> limit screws aren't in plane, they're twisted! It's a huge mess. Still have 
>> many good screws, bolts and springs worth saving. Jockey wheels, too. I'll 
>> leave it as-is and pull parts from it as needed. 
>>
>> On Sunday, July 23, 2023 at 8:19:03 PM UTC-4 Danny wrote:
>>
>>> Sorry about the hanger damage, but good to hear that you're ok. Even in 
>>> its pretzelized state, it's a good looking derailer sculpture!
>>>
>>> -Danny
>>>
>>>
>>> On Sun, Jul 23, 2023 at 6:42 PM Brian Turner  wrote:
>>>
>>>> I’m just over here hungry for pretzels.
>>>>
>>>> Seriously though, glad you’re ok, and I’m sorry about your Sam’s 
>>>> hanger. I’m sure it’ll be up and running strong again soon.
>>>>
>>>> On Jul 23, 2023, at 6:57 PM, Eric Marth  wrote:
>>>>
>>>> Thanks, Jim. Just a bit of my own patented brand of sarcasm ;) 
>>>>
>>>> The damage is waaay out of proportion to the fall. 
>>>>
>>>> On Sunday, July 23, 2023 at 5:57:30 PM UTC-4 J J wrote:
>>>>
>>>>> Wow... the most important thing is that you're fine, Eric. The bike 
>>>>> stuff is "just" bike stuff, repairable or replaceable.
>>>>>
>>>>> I saw your subject line and glanced at the pic before reading your 
>>>>> story, and at first I thought, "dang, did he get that thing to actually 
>>>>> work?!?"
>>>>>
>>>>> On Sunday, July 23, 2023 at 5:30:46 PM UTC-4 eric...@gmail.com wrote:
>>>>>
>>>>>> Dustin: To answer your question, hell no! 
>>>>>>
>>>>>> Ted: Gonna text the frame builder I know tomorrow. 
>>>>>>
>>>>>> Jared: Thanks! I'll share again when I have some updates. 
>>>>>>
>>>>>> On Sunday, July 23, 2023 at 4:01:11 PM UTC-4 jaredwilson wrote:
>>>>>>
>>>>>>> Yikes, that looks like a mess! 
>>>>>>>
>>>>>>> Glad you're okay and it's now another part of that Sam's history.
>>>>>>>
>>>>>>> Looking forward to seeing your repair updates.
>>>>>>>
>>>>>>> jared
>>>>>>>
>>>>>>> On Sunday, July 23, 2023 at 12:32:48 PM UTC-7 ted.l...@gmail.com 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Wow, I’m glad to hear that it was only a minor tumble, but I’m 
>>>>>>>> sorry to hear about the derailler… again. That’s quite the pretzel 
>>>>>>>> you’ve 
>>>>>>>> made, though! I’m not sure I’ve seen such, save for deraillers that 
>>>>>>>> went 
>>>>>>>> through a far more severe crash.
>>>>>>>>
>>>>>>>> I might be crazy, but restoring a busted up mech like that actually 
>>>>>>>> sounds like it would be a fun challenge. Hope the hanger can be fixed 
>>>>>>>> with 
>>>>>>>> minimal fuss but I think you may be right, a frame builder might be 
>>>>>>>> needed 
>>>>>>>> here. It always baffled me that Riv didn’t adopt replaceable hangers 
>>>>>>>> at 
>>>>>>>> some point along the line.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Jul 23, 2023 at 3:20 PM D D  wrote:
>>>>>>>>
>>>>>>>>> Eric,
>>>>>>>>>
>>>>>>>>> Sorry to hear about your misadventure. Thanks for the photo of the 
>>>>>>>>> pretzel. Did the photo you originally pulled over to take turn out to 
>>>>>>>>> be 
>>>>>>>>> worth it?  
>>>>>>>>>
>>>>>>>>> Dustin in VA
>>>>>>>&g

Re: Path issue Filesystem mounted with NFS(v4?)

[Chris Johns]

On 13/7/2023 10:29 pm, Heinz Junkes wrote:
> I see exact the same behavior as in the ticket 4273.
> Thanks for looking into….

This has been fixed.

Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

[RBW] Re: ISO Roadini...or?

[JohnS]

Hello Peter,

Wow, an '81 Sequoia! Those are very rare since only about 700 were made by 
hand. In '82 is when production ramped up. Please post a picture if you can.

Thanks,
John


On Friday, July 21, 2023 at 11:58:26 AM UTC-4 eric...@gmail.com wrote:

> Very nice build, Bones!  B) 
>
> On Friday, July 21, 2023 at 11:05:30 AM UTC-4 Bones wrote:
>
>> I started with an Appaloosa, which I built as a workhorse to ferry my 
>> kids around. I wanted something without all the racks and utility so I 
>> purchased a Hillborne. Great bike, but I found it too similar to my 
>> Appaloosa so I moved it along and bought a Roadini. It was exactly what I 
>> was looking for. No, it is not a delicate, lightweight bike. That is to my 
>> benefit, as I can do stupid things to it without worrying about it being 
>> damaged. It is a Rivendell, and it rides like all of my other Rivendells. 
>> It currently resides at my parents' house, and I make a point to ride it 
>> whenever I visit. I love that bike.
>>
>> [image: roadini2.jpg]
>>
>> Bones
>>
>> On Friday, July 21, 2023 at 1:49:48 AM UTC-4 chasenl...@gmail.com wrote:
>>
>>> [image: IMG_4997.jpeg]
>>>
>>> I am about 200 miles into my orange-ass roadini and I love it. Set up 
>>> with a23s, dirt drops, cavas and an analog 30mm stem. It is not flexy and 
>>> light like my rb 2. It is no sports car. Its like a benz, smooth and comfy. 
>>> I have a 90 stumpjumper (that I’m convinced could be the worlds greatest 
>>> bicycle), and the roadini is v similar, minus canti post, add practical 
>>> geometry. It is definitely stout, which makes the lack of rack mounts 
>>> annoying, but its not t stout. To me, it feels like a road tourer, not 
>>> a zippy speed machine. I think a crust mallochio or lightning bolt might be 
>>> lighter/flexier/zippier. 
>>> On Wednesday, July 19, 2023 at 10:03:16 PM UTC-4 Doug H. wrote:
>>>
 This paragraph is from Will's recent email... If this sounds like what 
 you're looking for then I say buy one. 

 "Yes, the Roadini is heavier than a carbon frame, but, and even though 
 it's a cliche phrase at this point, *it rides light* and I don't care 
 if I'm two minutes slower than my alternate-universe self who rides a 
 carbon bike. I still feel fast on it, and I'm not racing anybody anyway, 
 even myself. My bike priorities are safety, comfort, reliability, and the 
 ability to stretch the bike beyond it's stated purpose. Most of you aren't 
 able to come test ride one before you buy, but those that do invariably 
 say 
 something like, "it's faster than I thought it would be!". It's always 
 been 
 more about the rider than the frame, but I know what they mean."

 Doug


 On Wednesday, July 19, 2023 at 9:14:40 PM UTC-4 brenton...@gmail.com 
 wrote:

> Hi all,
>
> I have really fallen for these luscious new Roadini builds I've seen 
> at Riv and Blue Lug.
>
> I have a Sam Hillborne and love it. It's been through several 
> iterations of cockpit/racks/bags/brakes/wheels/tires and all have been 
> really fun. Right now it has flat bars with sweep, chunky 47mm tires, and 
> is an excellent all around adventure/trail/camping ride. It's currently 
> my 
> only bike!
>
> Before the Sam, I rode 90s road bikes exclusively for 20 years, and 
> those worked great for city/commuting/neighborhood/pub rides. I've heard 
> that the Roadini does NOT offer that kind of 
> ride/speed/feel/handling/gusto/whatever, from several folks in this group.
>
> So am I fooling myself into thinking another $2500 Riv build is going 
> to scratch the itch? Or should I buy a <$500 Japanese Road Bike that can 
> hold 33s and actually feel some performance?
>


-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/23f13d36-fa1f-4627-bd61-edeb22ed74b0n%40googlegroups.com.

Re: [PATCH] membench: Add memory benchmark programs

[Chris Johns]

On 21/7/2023 3:28 pm, Sebastian Huber wrote:
> On 21.07.23 03:27, Chris Johns wrote:
>> On 21/7/2023 3:51 am, Sebastian Huber wrote:
>>> On 20.07.23 18:58, Gedare Bloom wrote:
>>>> On Thu, Jul 20, 2023 at 7:42 AM Sebastian Huber
>>>>   wrote:
>>>>> These memory benchmark programs are not supposed to run.  Instead, they
>>>>> can be analysed on the host system to measure the memory usage of
>>>>> features.  See the membench module of rtems-central.
>>>>>
>>>> This needs some kind of documentation and probably a README inside of
>>>> membench with that information.
>>>
>>> Ok, I can add a README.md.
>>>
>>>>
>>>> This appears to be about benchmarking the program size (static memory
>>>> usage) only? If so, make that clear in the README / log note. I think
>>>> it's in the doxygen already so that's helpful.
>>>
>>> Yes, it measures only the static memory size required for certain operating
>>> system services. See 4.7 Memory Usage Benchmarks in:
>>>
>>> https://ftp.rtems.org/pub/rtems/people/sebh/rtems-6-sparc-gr740-uni-6-scf.pdf
>>
>> Should `static` be part of naming?
> 
> Yes, good idea.
> 
>>
>>>> What happens when the membench gets built, and then someone runs
>>>> $> rtems-test build/${ARCH}/${BSP}/testsuites
>>>>
>>>> Because I don't see anything that is filtering these executables.
>>>
>>> They are filtered out due to the *.norun.* pattern:>
>>> target: testsuites/membench/mem-scheduler-add-cpu.norun.exe
>>>
>>
>> Currently tests with `norun` assume the build fails if there is an issue 
>> with a
>> test. This is why we allow these tests and they are tagged `norun`.
> 
> We already have a couple of norun tests in libtests. This filtering is simple
> and works fine why would you want to change it?

I am not asking for that to change. After a build we will have a set of norun
tests and in that set are some that are be used for other purposes, eg memory
analysis, but that information is not available in the project. The norun could
be extended to be .norun.memstatic.exe and so the executables that form a
specific subset can be found and analysed.

The tests have been self contained for a long time and I would like that to
continue. ELF notes has been discussed in the past however we do not yet support
that so we need to find other ways to handling things.

>> Are they suppose to be checked or are they informational? Is something going 
>> to
>> be added to the project, for example in rtems-tools.git, to allow these 
>> tests to
>> be checked?
> 
> Currently, they are just informational,

I do not understand. What information, for what purpose and for whom?

> All the stuff to analyze this and work with
> the specification is in rtems-central.git. If you think this needs to be
> changed, then I am happy to discuss this.

Lets first understand the role these tests have. Adding them slows the build
down but that is OK if there is value in them for everyone.

> My preference is still to get rid of
> all the separate repositories and move everything back to rtems.git.

The qual work was separated for specific reasons. Those reasons are still valid.

> What is the plan for the CI flows?

I believe it is with Joel and Amar. I am waiting like everyone else.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] membench: Add memory benchmark programs

[Chris Johns]

On 21/7/2023 3:51 am, Sebastian Huber wrote:
> On 20.07.23 18:58, Gedare Bloom wrote:
>> On Thu, Jul 20, 2023 at 7:42 AM Sebastian Huber
>>   wrote:
>>> These memory benchmark programs are not supposed to run.  Instead, they
>>> can be analysed on the host system to measure the memory usage of
>>> features.  See the membench module of rtems-central.
>>>
>> This needs some kind of documentation and probably a README inside of
>> membench with that information.
> 
> Ok, I can add a README.md.
> 
>>
>> This appears to be about benchmarking the program size (static memory
>> usage) only? If so, make that clear in the README / log note. I think
>> it's in the doxygen already so that's helpful.
> 
> Yes, it measures only the static memory size required for certain operating
> system services. See 4.7 Memory Usage Benchmarks in:
> 
> https://ftp.rtems.org/pub/rtems/people/sebh/rtems-6-sparc-gr740-uni-6-scf.pdf

Should `static` be part of naming?

>> What happens when the membench gets built, and then someone runs
>> $> rtems-test build/${ARCH}/${BSP}/testsuites
>>
>> Because I don't see anything that is filtering these executables.
> 
> They are filtered out due to the *.norun.* pattern:>
> target: testsuites/membench/mem-scheduler-add-cpu.norun.exe
> 

Currently tests with `norun` assume the build fails if there is an issue with a
test. This is why we allow these tests and they are tagged `norun`.

I am happy to see these tests however I am not comfortable about the reference
and dependency to rtems-central to understand or analyse them. I have looked at
the test source and I do not understand their purpose. Are they generated?

Are they suppose to be checked or are they informational? Is something going to
be added to the project, for example in rtems-tools.git, to allow these tests to
be checked?

I am sorry, until I understand more about these tests, I have to say no. I would
much prefer to say yes but I will need a hand in understanding them.

My concern is simple. I make a change and it effects something in these tests
yet I have no ability to know if I have triggered a failure.

We will be adding CI flows to improve the quality of what we do and this
approach side steps that effort however I am not sure about this until I
understand more about them.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] Add two unit tests

[Chris Johns]

+1

Chris

On 21/7/2023 3:11 am, Gedare Bloom wrote:
> Looks good with a couple minor typo/grammar fixes.
> 
> On Thu, Jul 20, 2023 at 7:40 AM Sebastian Huber
>  wrote:
>>
>>
>> Frank Kühndel (2):
>>   unit: Test POSIX-specific message queue impl
>>   unit: Test unlimited objects configuration
>>
>>  .../build/testsuites/unit/unit-no-clock-0.yml |   2 +
>>  testsuites/unit/tc-config.c   | 171 +++
>>  testsuites/unit/tc-score-msgq.c   | 452 ++
>>  3 files changed, 625 insertions(+)
>>  create mode 100644 testsuites/unit/tc-config.c
>>  create mode 100644 testsuites/unit/tc-score-msgq.c
>>
>> --
>> 2.35.3
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder v3] bare/config: add renode rsb installation config

[Chris Johns]

OK to push.

Chris

On 21/7/2023 8:05 am, Muhammad Sulthan Mazaya wrote:
> Change file name based on Chris's review here 
> https://lists.rtems.org/pipermail/devel/2023-July/075802.html
> 
> Plus, fix `cp` so that it also include dotfiles. Because without the 
> the `.renode-root` file the command won't work.
> 
> ---
>  bare/config/devel/renode-1.13.3-1.cfg | 11 ++
>  bare/config/devel/renode.bset |  7 
>  source-builder/config/renode-1.cfg|  6 +++
>  source-builder/config/renode-common-1.cfg | 45 +++
>  4 files changed, 69 insertions(+)
>  create mode 100644 bare/config/devel/renode-1.13.3-1.cfg
>  create mode 100644 bare/config/devel/renode.bset
>  create mode 100644 source-builder/config/renode-1.cfg
>  create mode 100644 source-builder/config/renode-common-1.cfg
> 
> diff --git a/bare/config/devel/renode-1.13.3-1.cfg 
> b/bare/config/devel/renode-1.13.3-1.cfg
> new file mode 100644
> index 000..3b0b65f
> --- /dev/null
> +++ b/bare/config/devel/renode-1.13.3-1.cfg
> @@ -0,0 +1,11 @@
> +#
> +# Renode from Github release
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +%define renode_version 1.13.3
> +
> +%include %{_configdir}/renode-1.cfg
> diff --git a/bare/config/devel/renode.bset b/bare/config/devel/renode.bset
> new file mode 100644
> index 000..f89168d
> --- /dev/null
> +++ b/bare/config/devel/renode.bset
> @@ -0,0 +1,7 @@
> +#
> +# Build set for Renode
> +#
> +
> +%define release 1
> +
> +devel/renode-1.13.3-1
> diff --git a/source-builder/config/renode-1.cfg 
> b/source-builder/config/renode-1.cfg
> new file mode 100644
> index 000..b203797
> --- /dev/null
> +++ b/source-builder/config/renode-1.cfg
> @@ -0,0 +1,6 @@
> +#
> +#
> +# This configuration file configure's, make's and install's Renode.
> +#
> +
> +%include %{_configdir}/renode-common-1.cfg
> diff --git a/source-builder/config/renode-common-1.cfg 
> b/source-builder/config/renode-common-1.cfg
> new file mode 100644
> index 000..5c50298
> --- /dev/null
> +++ b/source-builder/config/renode-common-1.cfg
> @@ -0,0 +1,45 @@
> +#
> +# Renode from Github release
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +Name:  renode-%{renode_version}-%{_host}-%{release}
> +Summary:   Renode v%{renode_version}
> +Version:   %{renode_version}
> +Release:   %{release}
> +URL:http://www.renode.io
> +
> +#
> +# Renode source
> +# 
> +%source set renode 
> https://github.com/renode/renode/releases/download/v%{renode_version}/renode_%{renode_version}_source.tar.xz
> +
> +#
> +# Prepare the source code.
> +#
> +%prep
> +  build_top=$(pwd)
> +
> +  source_dir_renode="renode_%{renode_version}_source"
> +  %source setup renode -q -n renode_%{renode_version}_source
> +
> +  cd ${build_top}
> +
> +%build
> +  build_top=$(pwd)
> +
> +  cd ${source_dir_renode}
> +  ./build.sh
> +
> +  cd ${build_top}
> +
> +%install
> +  build_top=$(pwd)
> +
> +  mkdir -p %{_bindir}
> +  cp -r ./${source_dir_renode}/. %{_bindir}
> +
> +  cd ${build_top}
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/3] 6/7: Update Newlib

[Chris Johns]

OK to these updates.

Thanks
Chris

On 21/7/2023 5:03 am, Sebastian Huber wrote:
> Keep RTEMS up to date with the upstream development.
> ---
>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
>  rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-13-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
>  5 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> index e01542e..780a0ef 100644
> --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> @@ -17,12 +17,12 @@
>  %patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
>  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
>  
> -%define newlib_version 4c7d0df
> +%define newlib_version a021448
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
> +  
> YiC/BsmRpq8XsN1hx4s2Rvcwys/4DRFB3F6vvd+lEMJWXXpt3knXT4BBZkP11bkEcpDFCV9EaOlTT3HA7C3pCg==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> index 0eff966..99e2a21 100644
> --- a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> @@ -20,12 +20,12 @@
>  %patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
>  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
>  
> -%define newlib_version 4c7d0df
> +%define newlib_version a021448
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
> +  
> YiC/BsmRpq8XsN1hx4s2Rvcwys/4DRFB3F6vvd+lEMJWXXpt3knXT4BBZkP11bkEcpDFCV9EaOlTT3HA7C3pCg==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> index 7b0d4cb..0de9412 100644
> --- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> @@ -38,13 +38,13 @@
>  
> KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
>  # Comment above related to #4657 and patches ends here
>  
> -%define newlib_version 4c7d0df
> +%define newlib_version a021448
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \
> 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
> +  
> YiC/BsmRpq8XsN1hx4s2Rvcwys/4DRFB3F6vvd+lEMJWXXpt3knXT4BBZkP11bkEcpDFCV9EaOlTT3HA7C3pCg==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> index a507928..cd30ccf 100644
> --- a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> @@ -8,12 +8,12 @@
>  %hash sha512 %{gcc_expand_name}.tar.gz \
>
> Bap0yX4QA/1mQVQeUJyicdu1qUBsFapuJwxKKtfluFOUX11AtDpXzUL/wt6P7KvJKX5dDVWW8ZW4pIb8IAW3aw==
>  
> -%define newlib_version 4c7d0df
> +%define newlib_version a021448
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> 

Re: [RBW] ISO Roadini...or?

[JohnS]

I completed my '82 Specialized Sequoia build and couldn't be happier with 
it. Great feel, it has that, when I say jump, it says, how high feeling to 
it. It replaces my Surly Pacer which had a great fit but in comparison, was 
flat/dull. I'll post a few pics and a write up over the weekend. Highly 
recommend finding an early one if you can. Fits RH 700x32 tires cleanly, 
not sure if they would work with fenders, I'll check.

JohnS


On Thursday, July 20, 2023 at 8:24:18 AM UTC-4 Johnny Alien wrote:

> The RB's in the 90's were advertised as around 22 lb total for a mid-sized 
> frame and that was built with a lot of non-light parts. I would guess the 
> frame is lighter weight and flexier than a roadini.
>
> On Thursday, July 20, 2023 at 7:46:23 AM UTC-4 Eric Daume wrote:
>
>> If the Roadini with its double oversized tubing is lighter than an RB1… I 
>> would be very surprised. I’ve owned both, but probably 20 years apart. But 
>> tall head tubes, long chainstays, and heavy tubing all add up quickly. 
>>
>> Eric
>>
>>
>> On Thursday, July 20, 2023, exliontamer  wrote:
>>
>>> An RB-1 is a relatively heavy bike especially in 59cm & up & I wouldn't 
>>> be surprised if the Roadini is the same or possibly lighter. That said, I 
>>> don't think that's a bad thing depending on the frame size, your personal 
>>> pedaling style/power, weight, etc. When I was focused on only riding fast I 
>>> had a 59cm frame with EL/OS tubing that was very thin walled, flexy, & 
>>> light. I'm 6'1" & weighed 160lbs at the time & that bike was too whippy for 
>>> me personally. It took getting a '93 RB-1 (62cm wouldn't fit a 32 btw)  to 
>>> make me realize that I preferred a stiffer frame...also my average speed 
>>> increased even though the bike didn't "plane" & was 2 lbs heavier. 
>>>
>>> I'm glad Jan & that crew are doing their thing but the message can get 
>>> tedious. I'm sure it works for some people but a lot of it seems to be 
>>> presented in a one size fits all way. All that said there are a lot of 90s 
>>> steel frames that will fit a 28. Plenty of affordable lugged Bianchis that 
>>> will be lighter and less expensive than the RB-1. I also second the used 
>>> aluminum recommendation. Even the new Cannondale Optimo has clearance for 
>>> 32s and, as long as a carbon fork doesn't freak you out, starts at 1k for a 
>>> complete bike that's solidly spec'd and has rim brakes. 
>>> On Wednesday, July 19, 2023 at 11:27:12 PM UTC-5 Joe Bernard wrote:
>>>
>>>> It's sacrilege to say but if you want a zippy road bike as a compliment 
>>>> to what you already have - a steel Rivendell road bike - for $1000 or less 
>>>> you can scoop up an aluminum Trek/Cannondale/Specialized/Giant off 
>>>> Craigslist and probably have a lot of fun. And you can test ride it! 
>>>>
>>>> On Wednesday, July 19, 2023 at 6:14:40 PM UTC-7 brenton...@gmail.com 
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I have really fallen for these luscious new Roadini builds I've seen 
>>>>> at Riv and Blue Lug.
>>>>>
>>>>> I have a Sam Hillborne and love it. It's been through several 
>>>>> iterations of cockpit/racks/bags/brakes/wheels/tires and all have been 
>>>>> really fun. Right now it has flat bars with sweep, chunky 47mm tires, and 
>>>>> is an excellent all around adventure/trail/camping ride. It's currently 
>>>>> my 
>>>>> only bike!
>>>>>
>>>>> Before the Sam, I rode 90s road bikes exclusively for 20 years, and 
>>>>> those worked great for city/commuting/neighborhood/pub rides. I've heard 
>>>>> that the Roadini does NOT offer that kind of 
>>>>> ride/speed/feel/handling/gusto/whatever, from several folks in this group.
>>>>>
>>>>> So am I fooling myself into thinking another $2500 Riv build is going 
>>>>> to scratch the itch? Or should I buy a <$500 Japanese Road Bike that can 
>>>>> hold 33s and actually feel some performance?
>>>>>
>>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "RBW Owners Bunch" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to rbw-owners-bun...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/rbw-owners-bunch/854bd364-6c73-477e-b2bb-3bc8b67b11c3n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/rbw-owners-bunch/854bd364-6c73-477e-b2bb-3bc8b67b11c3n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/49ac0795-0e96-4bce-854e-a3eed0ae4347n%40googlegroups.com.

Re: [PATCH rtems-libbsd/6-freebsd-12 2/3] syscall/open: Reference the path info directory vnode

[Chris Johns]

On 20/7/2023 5:24 pm, Cedric Berger wrote:
> On 20.07.23 07:45, chr...@rtems.org wrote:
> 
>> From: Chris Johns 
>>
>> The kernel open call requires a path so to open a file we need to
>> set the current directory to the parent vnode. If the open mode is
>> create the path info vnode is the directory to perform the open
>> create in. Using the parent node creates the file in wrong path.
>>
>> Updates #4723
>> ---
>>   rtemsbsd/rtems/rtems-bsd-syscall-api.c | 24 ++---
>>   testsuite/nfs01/test_main.c    | 75 --
>>   2 files changed, 64 insertions(+), 35 deletions(-)
>>
>> diff --git a/rtemsbsd/rtems/rtems-bsd-syscall-api.c
>> b/rtemsbsd/rtems/rtems-bsd-syscall-api.c
>> index 76fc8ad7..cfceb768 100644
>> --- a/rtemsbsd/rtems/rtems-bsd-syscall-api.c
>> +++ b/rtemsbsd/rtems/rtems-bsd-syscall-api.c
>> @@ -931,9 +931,18 @@ rtems_bsd_sysgen_open_node(
>>   } else {
>>   rtems_filesystem_location_info_t *rootloc =
>>   >pathinfo.mt_entry->mt_fs_root->location;
>> +    /*
>> + * We need the parent directory so open can find the
>> + * the entry. If we are creating the file the pathinfo
> 
> the the

Yeah and thanks for the review. I think this should be:

/*
 * We need the parent directory so open can find the
 * entry. If we are creating the file the pathinfo
 * vnode entry is the directory to open uses to create
 * the file in.
 */

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB] rtems-net-legacy: Update net and waf versions

[Chris Johns]

Looks good.

Thanks
Chris

On 20/7/2023 11:17 am, Vijay Kumar Banerjee wrote:
> ---
>  rtems/config/tools/rtems-net-legacy-6.cfg | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg 
> b/rtems/config/tools/rtems-net-legacy-6.cfg
> index 9193a58..559ec01 100644
> --- a/rtems/config/tools/rtems-net-legacy-6.cfg
> +++ b/rtems/config/tools/rtems-net-legacy-6.cfg
> @@ -3,10 +3,10 @@
>  #
>  
>  #  branch: main
> -%define rtems_net_version ba35f73d2ddc82d2b9a7b728dc63552be2274968
> +%define rtems_net_version 3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2
>  %hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.bz2 \
> -   
> EljXAoCCIpFgncarsSR9V/WczB3VO9+VqTsJfrkvOCpwCuO8SWY6GTM46DnvyKBUrmkv0Rk+0TBdOifuYaMMug==
> -%define rtems_waf_version 2c15b90de5c369aa78cd2252a50bba677e9b13f3
> +   
> ANUrgSU3YRAnbEM/9wL5R4LrRCcyDYZz9KbRhTxnNYvUPjrfNgO+bM1qEYtJI6qUxvlKZYkVIkeOKxsAtjj1/A==
> +%define rtems_waf_version 68654b4f995382765605dc16917baad4bdbf7f7c
>  %hash sha512 rtems-waf-%{rtems_waf_version}.tar.bz2 \
> -   
> gSpj/vTcB9T985HC9xi//gMcYj9rl6AedULvPdFppJ7D1CFIueE+MyfGn+okVtZvnG+tZk1JkR2gvIQNV3mXbQ==
> +   
> NAuyFxjfSiQd6VfYZl4fJClywPrLF2fN+GjXHjq3ddceqaBrSeHZ+XpYpU3XTnk2qKICsUSTLV+CskDuWdwqvQ==
>  %include tools/rtems-net-legacy-common.cfg
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems] powerpc/beatnik: Remove RTEMS_NETWORKING check from bsp.h

[Chris Johns]

Looks good.

Thanks
Chris

On 20/7/2023 10:15 am, Vijay Kumar Banerjee wrote:
> ---
>  bsps/powerpc/beatnik/include/bsp.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/bsps/powerpc/beatnik/include/bsp.h 
> b/bsps/powerpc/beatnik/include/bsp.h
> index 477f03345d..a70bb3997f 100644
> --- a/bsps/powerpc/beatnik/include/bsp.h
> +++ b/bsps/powerpc/beatnik/include/bsp.h
> @@ -173,12 +173,10 @@ extern void BSP_motload_pci_fixup(void);
>  int BSP_i2c_initialize(void);
>  
>  /* Networking; */
> -#if defined(RTEMS_NETWORKING)
>  #include 
>  int rtems_em_attach(struct rtems_bsdnet_ifconfig *, int);
>  int rtems_dec21140_driver_attach(struct rtems_bsdnet_ifconfig *, int);
>  int rtems_dc_driver_attach(struct rtems_bsdnet_ifconfig *, int);
> -#endif
>  
>  /* NOT FOR PUBLIC USE BELOW HERE */
>  #define BSP_PCI_HOSE0_MEM_BASE0x8000  /* must be aligned to size */
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-net-legacy] powerpc/beatnik: Add mv643xx_eth.c driver from RTEMS 5

[Chris Johns]

On 20/7/2023 10:18 am, Vijay Kumar Banerjee wrote:
> On Wed, Jul 19, 2023 at 6:39 PM Chris Johns  wrote:
>>
>> Excellent.
>>
>> Could you please update the hash in the RSB for the net legacy package?
>>
> Thanks for mentioning it! While trying to build from RSB, I realized
> two important changes I need from rtems build:
> 1. Removing networking check, put a patch for it just now:
> https://lists.rtems.org/pipermail/devel/2023-July/075830.html

I saw that.

> 2. Building the ping and telnetd02 requires posix. For this, should be
> conditionally build these two tests only when RTEMS_POSIX_API is true?

Which part of POSIX is needed? I ask because I think the POSIX option is only
controlling signals and maybe something else, I cannot remember what the list
is. What happens if you remove the check?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5.3 libbsd, networking issue for 100mbps link (1Gbps is fine)

[Chris Johns]

On 18/7/2023 8:21 pm, Karol Gliwa wrote:
> Hi Guys,
> 
>  
> 
> I have following problem with networking on Zynq running RTEMS 5.3 + libbsd +
> BSP zynq_zedboard of according version.
> 
> I had to patch the libbsd to support some network PHY for the boards I use.
> 
>  
> 
> Whenever I connect the device to 1Gbit interface, and the link is negotiated 
> to
> 1Gbit everything seems working just fine. I can PING the board and 
> successfully
> connect to TCP/IP socket (custom test echo server basing on the examples int 
> the
> rtems-libbsd repository + sockets).
> 
>  
> 
> When I connect the board to 100Mbit interface (another usb dongle) it seems to
> establish the link fine, but I cannot ping the board nor connect to the 
> socket.
> I replicated this behavior with at least three different 1Gbit interfaces 
> (works
> each time) and two 100Mbit dongles (not working). I confirmed that behavior
> using PYNQ Z1 board and also with our other custom device.
> 
>  
> 
> Additionally, I had an opportunity to test our custom board with another 
> 'hello
> world' echo server that came from my colleges that use Xilin'x Vitis + LwIP
> (bare metal application) and that one has been working in every link speed
> configuration.
> 
>  
> 
> It seems to me that the problem my reside in the RTEMS software part or 
> drivers
> (or my compilation or configuration) and not in the HW since I could confirm
> it's working with LwIP for all configs... Unfortunately, I have little
> experience with networking in general and was not able to solve that issue on 
> my
> own.
> 
>  
> 
> I attach the RTEMS shell output of `ifconfig -a` executed on PYNQ Z1 when
> connected to 1Gbit eth device (PING working):
> 
>  
> 
> '''
> 
> SHLL [/] # ifconfig  cgem0 192.168.10.207 netmask 255.255.255.0
> 
> SHLL [/] # ifconfig -a   
> 
> cgem0: flags=8843 metric 0 mtu 1500
> 
>     options=80008
> 
>     ether 0e:b0:ba:5e:ba:11
> 
>     inet6 fe80::cb0:baff:fe5e:ba11%cgem0 prefixlen 64 scopeid 0x1
> 
>     inet 192.168.10.207 netmask 0xff00 broadcast 192.168.10.255
> 
>     nd6 options=21
> 
>     media: Ethernet autoselect (1000baseT )
> 
>     status: active
> 
> lo0: flags=8049 metric 0 mtu 16384
> 
>     options=680003
> 
>     inet 127.0.0.1 netmask 0xff00
> 
>     inet6 ::1 prefixlen 128
> 
>     inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> 
>     nd6 options=21
> 
>     groups: lo
> 
> '''
> 
>  
> 
>  
> 
> Then hot switch to 100Mbit usb eth card (PING not working):
> 
> '''
> 
> SHLL [/] # info: cgem0: link state changed to DOWN
> 
> cgem0: cgem_mediachange: could not set ref clk0 to 2500.
> 
> info: cgem0: link state changed to UP
> 
> SHLL [/] # ifconfig  cgem0 172.19.1.207 netmask 255.255.255.0 
> 
> SHLL [/] # ifconfig -a 
> 
> cgem0: flags=8843 metric 0 mtu 1500
> 
>     options=80008
> 
>     ether 0e:b0:ba:5e:ba:11
> 
>     inet6 fe80::cb0:baff:fe5e:ba11%cgem0 prefixlen 64 scopeid 0x1
> 
>     inet 172.19.1.207 netmask 0xff00 broadcast 172.19.1.255
> 
>     nd6 options=21
> 
>     media: Ethernet autoselect (100baseTX )
> 
>     status: active
> 
> lo0: flags=8049 metric 0 mtu 16384
> 
>     options=680003
> 
>     inet 127.0.0.1 netmask 0xff00
> 
>     inet6 ::1 prefixlen 128
> 
>     inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> 
>     nd6 options=21
> 
>     groups: lo
> 
> '''
> 
>  
> 
>  
> 
>  
> 
> Do You have any idea of what may be causing the issue here? Thanks for all 
> help
> in advance.

Are the clocks to the PHY being correctly set and the driver knows the 
frequency.

Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: HEADS UP: git repo WRONG push landed.

[Chris Johns]

Amar as edited the repo. You can read his post here ..

https://lists.rtems.org/pipermail/devel/2023-July/075819.html

Chris

On 19/7/2023 12:13 am, Brett Sterling wrote:
> The easiest way to do this is to revert and push.  'unpushing' is not
> recommended :-)
> 
> Brett
> 
> *From:* users  on behalf of Karel Gardas
> 
> *Sent:* Tuesday, July 18, 2023 7:58 AM
> *To:* users@rtems.org 
> *Subject:* HEADS UP: git repo WRONG push landed.
>  
> [You don't often get email from karel.gar...@centrum.cz. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification
>  ]
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the content
> is safe.
> 
> 
>    Dear RTEMS users,
> 
> if you are using RTEMS git repo, please do not pull now. Wrong patches
> landed in the main RTEMS git.rtems.org and they needs to be removed.
> 
> Thanks for your patience!
> Karel
> 
> 
>  Forwarded Message 
> Subject: HEADS UP: git repo WRONG push landed.
> Date: Tue, 18 Jul 2023 15:40:11 +0200
> From: Karel Gardas 
> To: rtems-de...@rtems.org 
> 
> 
>    Folks,
> 
> I've completely screwed up and pushed wrong repository to the git.rtems.org.
> 
> I don't know how that happen as this should land on github.com...
> 
> So please do not commit anything for now, I'll try to lookup help on
> discord.com and see what can be done to unpush...
> 
> Thanks and really sorry for this mess...
> 
> Karel
> ___
> devel mailing list
> de...@rtems.org
> https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Flists.rtems.org%2Fmailman%2Flistinfo%2Fdevel=05%7C01%7C%7Cdf082186a2e94e7469a508db87972228%7Cd761ffacf6be45b88f6f288a59577095%7C0%7C0%7C638252855427392820%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=KaysoMVjUZ3z52kLfaNS1xmwbdN5Y3YmOQLPiYCUHlI%3D=0
>  
> 
> ___
> users mailing list
> users@rtems.org
> https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Flists.rtems.org%2Fmailman%2Flistinfo%2Fusers=05%7C01%7C%7Cdf082186a2e94e7469a508db87972228%7Cd761ffacf6be45b88f6f288a59577095%7C0%7C0%7C638252855427392820%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hcdP78m3VZM%2BhIPEluZSxF45bbuMfkuWqBGByQxtMSs%3D=0
>  
> 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: [PATCH rtems v2] Add the Regulator Interface and test

[Chris Johns]

On 15/7/2023 9:48 am, Joel Sherrill wrote:
> Updates #4924.
> 
> The Regulator is an application support class which is used to
> deal with the scenario where there is a bursty input source
> which needs to be metered out to a destination sink. The maximum
> size of bursts needs to be known and the delivery method must
> be configured to deliver messages at a rate that allows the
> traffic to not overflow.
> ---
>  cpukit/include/rtems/regulator.h  |  439 ++
>  cpukit/include/rtems/regulatorimpl.h  |  103 ++
>  cpukit/libmisc/regulator/regulator.c  |  522 
>  spec/build/cpukit/librtemscpu.yml |2 +
>  spec/build/cpukit/objregulator.yml|   18 +
>  spec/build/testsuites/libtests/grp.yml|2 +
>  .../build/testsuites/libtests/regulator01.yml |   21 +
>  testsuites/libtests/regulator01/regulator01.c | 1192 +
>  .../libtests/regulator01/regulator01.doc  |   68 +
>  .../libtests/regulator01/rtems_config.c   |   59 +
>  10 files changed, 2426 insertions(+)
>  create mode 100644 cpukit/include/rtems/regulator.h
>  create mode 100644 cpukit/include/rtems/regulatorimpl.h
>  create mode 100644 cpukit/libmisc/regulator/regulator.c
>  create mode 100644 spec/build/cpukit/objregulator.yml
>  create mode 100644 spec/build/testsuites/libtests/regulator01.yml
>  create mode 100644 testsuites/libtests/regulator01/regulator01.c
>  create mode 100644 testsuites/libtests/regulator01/regulator01.doc
>  create mode 100644 testsuites/libtests/regulator01/rtems_config.c
> 
> diff --git a/cpukit/include/rtems/regulator.h 
> b/cpukit/include/rtems/regulator.h
> new file mode 100644
> index 00..74f0d00f2e
> --- /dev/null
> +++ b/cpukit/include/rtems/regulator.h
> @@ -0,0 +1,439 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @defgroup RegulatorAPI Regulator API
> + *
> + * @brief Regulator APIs
> + *
> + * The Regulator provides a set of APIs to manage input sources which 
> + * produces bursts of message traffic.
> + */
> +
> +/**
> + * @mainpage
> + *
> + * The regulator is designed to sit logically between two entities -- a
> + * source and a sink/destination, where it limits the traffic sent to the
> + * destination to prevent it from being flooded with messages from the
> + * source. This can be used to accommodate bursts of input from a source
> + * and meter it out to a destination.  The maximum number of messages
> + * which can be buffered in the regulator is specified by the
> + * @a maximum_messages field in the @a rtems_regulator_attributes
> + * structure passed as an argument to @a rtems_regulator_create().
> + *
> + * The regulator library accepts an input stream of messages from a
> + * source and delivers them to a destination. The regulator assumes that the
> + * input stream from the source contains sporadic bursts of data which can
> + * exceed the acceptable rate of the destination. By limiting the message 
> rate,
> + * the regulator prevents an overflow of messages.
> + *
> + * The regulator can be configured for the input buffering required to manage
> + * the maximum burst and for the metering rate for the output. The output 
> rate
> + * is in messages per second. If the sender produces data too fast, the
> + * regulator will buffer the configured number of messages.
> + *
> + * A configuration capability is provided to allow for adaptation to 
> different
> + * message streams. The regulator can also support running multiple 
> instances,
> + * which could be used on independent message streams.
> + *
> + * The regulator provides a simple interface to the application for avoiding
> + * bursts of input from a fast source overflowing a slower output sink.
> + *
> + * It is assumed that the application has a design limit on the number of
> + * messages which may be buffered. All messages accepted by the regulator,
> + * assuming no overflow on input, will eventually be output by the delivery
> + * thread.
> + *
> + * A regulator instance is used as follows:
> + *
> + * @code
> + *   while (1)
> + * use rtems_regulator_obtain_buffer to obtain a buffer
> + * input operation to fetch data into the buffer
> + * rtems_regulator_send(buffer, size of message)
> + *   // rtems_regulator_send() will release the buffer automatically 
> when done

OK however ...

> + * @endcode
> + *
> + * The sequence diagram below shows the interaction between a message Source,
> + * a Regulator instance, and RTEMS, given the usage described in the above
> + * paragraphs.
> + *
> + * \startuml "Regulator Application Input Source Usage"
> + *   Source -> Regulator : rtems_regulator_obtain_buffer(regulator, buffer)
> + *   Regulator -> RTEMS : rtems_partition_get_buffer(id, buffer)
> + *   RTEMS --> Regulator : rtems_status_code
> + *   Regulator --> Source : rtems_status_code
> + *   Source -> Regulator : rtems_regulator_send(regulator, message, length)
> + *   Regulator -> RTEMS : 

Re: [PATCH rtems-docs] user: Update @rtems-ver-major@ to use sphinx substitution extention

[Chris Johns]

On 18/7/2023 6:16 pm, Muhammad Sulthan Mazaya wrote:
>  Using sphinx-substitution-extensions to manage the variable 
> @rtems-ver-major@. 
>  Originally Utkarsh's idea: 
>  
> https://discord.com/channels/82045382112799/82045848335924/1118416996606943302
>  
>  I have tested and built the docs to see if it works and it does 
>  subtitute the variable. The changes are: the variable @rtems-ver-major@ 
>  is now |rtems-ver-major|. For inline code block we use 
>  :substitution-code:`{content}` and for multiline code block we use:
> 
>  .. code-block:: {language}
>:substitutions:
>
>{content}

This is a welcome update to the documentation. Thank you for looking into it.

Does this patch require any additional sphinx modules to be installed?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder v2] bare/config: add renode rsb installation config

[Chris Johns]

On 12/7/2023 6:43 pm, Muhammad Sulthan Mazaya wrote:
> Use the design of how qemu handle config files + add version number to
> the config file name.
> 
> ---
>  bare/config/devel/renode-1.13.3-1.cfg | 11 ++
>  bare/config/devel/renode.bset |  7 
>  source-builder/config/renode-1.13.3.cfg   |  7 
>  source-builder/config/renode-common-1.cfg | 45 +++
>  4 files changed, 70 insertions(+)
>  create mode 100644 bare/config/devel/renode-1.13.3-1.cfg
>  create mode 100644 bare/config/devel/renode.bset
>  create mode 100644 source-builder/config/renode-1.13.3.cfg

What happens if a new dot release comes out? Maybe this should be renode-1.cfg
and we only look at this file again if the major release changes?

Chris

>  create mode 100644 source-builder/config/renode-common-1.cfg
> 
> diff --git a/bare/config/devel/renode-1.13.3-1.cfg 
> b/bare/config/devel/renode-1.13.3-1.cfg
> new file mode 100644
> index 000..ad9b0ad
> --- /dev/null
> +++ b/bare/config/devel/renode-1.13.3-1.cfg
> @@ -0,0 +1,11 @@
> +#
> +# Renode from git
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +%define renode_version 1.13.3
> +
> +%include %{_configdir}/renode-1.13.3.cfg
> diff --git a/bare/config/devel/renode.bset b/bare/config/devel/renode.bset
> new file mode 100644
> index 000..f89168d
> --- /dev/null
> +++ b/bare/config/devel/renode.bset
> @@ -0,0 +1,7 @@
> +#
> +# Build set for Renode
> +#
> +
> +%define release 1
> +
> +devel/renode-1.13.3-1
> diff --git a/source-builder/config/renode-1.13.3.cfg 
> b/source-builder/config/renode-1.13.3.cfg
> new file mode 100644
> index 000..5aff341
> --- /dev/null
> +++ b/source-builder/config/renode-1.13.3.cfg
> @@ -0,0 +1,7 @@
> +#
> +# Renode 1.13.3 Version 1.
> +#
> +# This configuration file configure's, make's and install's Renode.
> +#
> +
> +%include %{_configdir}/renode-common-1.cfg
> diff --git a/source-builder/config/renode-common-1.cfg 
> b/source-builder/config/renode-common-1.cfg
> new file mode 100644
> index 000..65be946
> --- /dev/null
> +++ b/source-builder/config/renode-common-1.cfg
> @@ -0,0 +1,45 @@
> +#
> +# Renode from git
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +Name:  renode-%{renode_version}-%{_host}-%{release}
> +Summary:   Renode v%{renode_version}
> +Version:   %{renode_version}
> +Release:   %{release}
> +URL:http://www.renode.io
> +
> +#
> +# Renode source
> +#
> +%source set renode 
> https://github.com/renode/renode/releases/download/v%{renode_version}/renode_%{renode_version}_source.tar.xz
> +
> +#
> +# Prepare the source code.
> +#
> +%prep
> +  build_top=$(pwd)
> +
> +  source_dir_renode="renode_%{renode_version}_source"
> +  %source setup renode -q -n renode_%{renode_version}_source
> +
> +  cd ${build_top}
> +
> +%build
> +  build_top=$(pwd)
> +
> +  cd ${source_dir_renode}
> +  ./build.sh
> +
> +  cd ${build_top}
> +
> +%install
> +  build_top=$(pwd)
> +
> +  mkdir -p %{_bindir}
> +  cp -r ./${source_dir_renode}/* %{_bindir}
> +
> +  cd ${build_top}
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Path issue Filesystem mounted with NFS(v4?)

[Chris Johns]

On 11/7/2023 7:32 pm, Heinz Junkes wrote:
> Hallo,
> 
> I am observing a strange problem with an NFS(v4) mounted filesystem and path 
> usage.
> 
> I have mounted a filesystem via NFSv4 (/Volumes):
> 
> loc = 0x00820a20
> node_access = 0x007c2378, node_access_2 = 0x, handler = 0x005c3474
> type = nfs, mounted, read-write, target = /Volumes, dev = 141.14.131.192, 
> root loc = 0x00913468
> 
> In the shell I can change there into a directory:
> 
> SHLL [/] # cd /Volumes/Epics/LogDir/Database
> SHLL [/Volumes/Epics/LogDir/Database] # pwd
> /Volumes/Epics/LogDir/Database
> 
> SHLL [/Volumes/Epics/LogDir/Database] # ls -l
> total 20
> -rw-r--r--  1 1001  1001  10694 Mar 23  2021 iocvmeIOC3.dbhcr
> -rw-r--r--  1 1001  1001  0 Mar 23  2021 iocvmeIOC3.dbior
> -rw-r--r--  1 1001  1001   5451 Mar 23  2021 iocvmeIOC3.dbl
> 
> I can now copy a file to here:
> 
> SHLL [/Volumes/Epics/LogDir/Database] # cp /etc/passwd .
> SHLL [/Volumes/Epics/LogDir/Database] # ls -l
> total 24
> -rw-r--r--  1 1001   1001   10694 Mar 23  2021 iocvmeIOC3.dbhcr
> -rw-r--r--  1 1001   1001   0 Mar 23  2021 iocvmeIOC3.dbior
> -rw-r--r--  1 1001   10015451 Mar 23  2021 iocvmeIOC3.dbl
> -rwxrwxrwt  1 65534  65534 14 Jul 11 11:28 passwd
> SHLL [/Volumes/Epics/LogDir/Database] # cat passwd
> root::0:0
> SHLL [/Volumes/Epics/LogDir/Database] # rm passwd
> SHLL [/Volumes/Epics/LogDir/Database] # ls -l
> total 20
> -rw-r--r--  1 1001  1001  10694 Mar 23  2021 iocvmeIOC3.dbhcr
> -rw-r--r--  1 1001  1001  0 Mar 23  2021 iocvmeIOC3.dbior
> -rw-r--r--  1 1001  1001   5451 Mar 23  2021 iocvmeIOC3.dbl
> 
> If I now specify the path instead of “.”, the file appears one dir up 
> 
> SHLL [/Volumes/Epics/LogDir/Database] # cp /etc/passwd 
> /Volumes/Epics/LogDir/Database/passwd
> SHLL [/Volumes/Epics/LogDir/Database] # ls -l
> total 20
> -rw-r--r--  1 1001  1001  10694 Mar 23  2021 iocvmeIOC3.dbhcr
> -rw-r--r--  1 1001  1001  0 Mar 23  2021 iocvmeIOC3.dbior
> -rw-r--r--  1 1001  1001   5451 Mar 23  2021 iocvmeIOC3.dbl
> SHLL [/Volumes/Epics/LogDir/Database] # ls -l ..
> total 40
> drwxrwxrwx  2 65534  65534  4096 Jul 11 11:29 Database
> -rwxrwxrwt  1 65534  65534  9980 Jul 10 11:52 iocvmeIOC1.dbhcr
> -rwsrwsrwt  1 65534  65534 0 Jul 10 11:52 iocvmeIOC1.dbior
> -rwxrwxrwt  1 65534  65534  4713 Jul 10 11:59 iocvmeIOC1.dbl
> drwxrwxrwx  3 65534  65534  4096 Mar 23  2021 log
> -rwxrwxrwt  1 65534  6553414 Jul 11 11:30 passwd
> SHLL [/Volumes/Epics/LogDir/Database] # cat ../passwd
> root::0:0
> 
> 
> Any Idea what might go wrong? Any fix?

Is it related to https://devel.rtems.org/ticket/4723?

I was planning to look into this in the next couple of weeks.

Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: [PATCH rtems v1] Add the Regulator Interface and test

[Chris Johns]

Hi,

Thanks for posting this code. My comments are below and I hope they help.

Thanks
Chris

On 8/7/2023 6:55 am, Joel Sherrill wrote:
> Updates #4924.
> 
> The Regulator is an application support class which is used to
> deal with the scenario where there is a bursty input source
> which needs to be metered out to a destination sink. The maximum
> size of bursts needs to be known and the delivery method must
> be configured to deliver messages at a rate that allows the
> traffic to not overflow.
> ---
>  cpukit/include/rtems/regulator.h  |  360 +
>  cpukit/include/rtems/regulatorimpl.h  |  100 ++
>  cpukit/regulator/regulator.c  |  487 +++

I prefer we do not add pieces of functionality to cpukit at this level. You
mention this is application support so would `libapp` work? It would allow for
growth, eg logging. We have separate libraries for libdl etc so should this be
separate or placed in libcpu? We also have libmisc and it could live there?

FYI and unrelated I also think moving dtc, ftpd, mghttpd, compression and
telnetd somewhere would be good.

>  spec/build/cpukit/librtemscpu.yml |3 +
>  spec/build/testsuites/libtests/grp.yml|2 +
>  .../build/testsuites/libtests/regulator01.yml |   21 +
>  testsuites/libtests/regulator01/regulator01.c | 1156 +
>  .../libtests/regulator01/regulator01.doc  |   37 +
>  .../libtests/regulator01/rtems_config.c   |   59 +
>  9 files changed, 2225 insertions(+)
>  create mode 100644 cpukit/include/rtems/regulator.h
>  create mode 100644 cpukit/include/rtems/regulatorimpl.h
>  create mode 100644 cpukit/regulator/regulator.c
>  create mode 100644 spec/build/testsuites/libtests/regulator01.yml
>  create mode 100644 testsuites/libtests/regulator01/regulator01.c
>  create mode 100644 testsuites/libtests/regulator01/regulator01.doc
>  create mode 100644 testsuites/libtests/regulator01/rtems_config.c
> 
> diff --git a/cpukit/include/rtems/regulator.h 
> b/cpukit/include/rtems/regulator.h
> new file mode 100644
> index 00..7344ced2ae
> --- /dev/null
> +++ b/cpukit/include/rtems/regulator.h
> @@ -0,0 +1,360 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @defgroup RegulatorAPI Regulator API
> + *
> + * @brief Regulator APIs
> + *
> + * The Regulator provides a set of APIs to manage bursty message traffic.
> + */
> +
> +/**
> + * @mainpage
> + *
> + * The regulator is designed to sit logically between two entities -- a
> + * source and a destination, where it limits the traffic sent to the
> + * destination to prevent it from being flooded with messages from the
> + * source. This can be used to accommodate bursty input from a source

... bursts of input ...

> + * and meter it out to a destination.
> + *
> + * The regulator library accepts an input stream of messages from a
> + * source and delivers them to a destination. The regulator assumes that the
> + * input stream from the source contains sporadic bursts of data which can
> + * exceed the acceptable rate of the destination. By limiting the message 
> rate,
> + * the regulator prevents an overflow of messages.
> + *
> + * The regulator can be configured for the input buffering required to manage
> + * the maximum burst and for the metering rate for the output. The output 
> rate

How is the maximum burst defined?

> + * is in messages per second. If the sender produces data too fast, the
> + * regulator will buffer the configured number of messages.

What happens to the input data when the "configured number of messages" limit is
reached?

There is no discussion about error, error responiblity and recovery.

> + * A configuration capability is provided to allow for adaptation to 
> different
> + * message streams. The regulator can also support running multiple 
> instances,
> + * which could be used on independent message streams.
> + *
> + * The regulator provides a simple interface to the application for avoiding
> + * bursty input from a fast source overflowing a slower output sink.
> + *
> + * It is assumed that the application has a design limit on the number of
> + * messages which may be buffered. All messages will eventually be output.

Does the regulator provide any stats, latched states or alarms to help a user
integrate and prove the data flows are operating as designed? I have
successfully used high or low water marks as a way to help audit this type of
functionality in systems. The marks are set at the system level and can be
manually checked or monitored to make sure no system limits are beached. Slient
drops or overflows can be difficult to resolve.

> + *
> + * A regulator instance is used as follows:
> + *
> + * @code
> + *   while (1)
> + * use rtems_regulator_obtain_buffer to obtain a buffer
> + * input operation to fetch data into the buffer
> + * rtems_regulator_send(buffer, size of message)
> + *   // rtems_regulator_send() will release the buffer automatically 

Re: Add currently best clang-format configuration to repository?

[Chris Johns]

On 6/7/2023 11:59 am, Gedare Bloom wrote:
> On Wed, Jul 5, 2023 at 5:27 PM Chris Johns  wrote:
>>
>> On 6/7/2023 4:21 am, Gedare Bloom wrote:
>>> OK I will prepare something soon. I have my WIP version at
>>> https://git.rtems.org/gedare/rtems.git/tree/_clang-format?h=test-reformat
>>>
>>> I think the format file itself should be just about stable. I will
>>> make one more test and check of it within the next few days, and then
>>> send the patch hopefully early next week.
>>
>> How will the version of clang-format we need be handled?
>>
>> Will an older version complain if our style is used with it? I am concerned I
>> use and trust the output however I make a mistake and use an old clang-format
>> that does not generate the correct format. I doubt I would spot that 
>> happening
>> when reviewing the output.
>>
> Certain (new) options in the style file will/can trigger an error that
> terminates the reformatting in (older) versions of clang-format that
> don't support the given option. I think we would be in that territory
> with our style.

Sounds good.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add currently best clang-format configuration to repository?

[Chris Johns]

On 6/7/2023 4:21 am, Gedare Bloom wrote:
> OK I will prepare something soon. I have my WIP version at
> https://git.rtems.org/gedare/rtems.git/tree/_clang-format?h=test-reformat
> 
> I think the format file itself should be just about stable. I will
> make one more test and check of it within the next few days, and then
> send the patch hopefully early next week.

How will the version of clang-format we need be handled?

Will an older version complain if our style is used with it? I am concerned I
use and trust the output however I make a mistake and use an old clang-format
that does not generate the correct format. I doubt I would spot that happening
when reviewing the output.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems_waf Include File Detection Question

[Chris Johns]

On 6/7/2023 8:24 am, Joel Sherrill wrote:
> I have a case for an addition to rtems-examples where I want to know if a
> particular header file is installed before enabling the example. How does one 
> do
> that in rtems_waf/wscripts?

https://git.rtems.org/rtems_waf/tree/rtems_bsd.py#n65 ...

  conf.check(header_name='dlfcn.h', features='c')

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Tool versions for RTEMS 6.1 release?

[Chris Johns]

On 3/7/2023 5:35 pm, Sebastian Huber wrote:
> On 03.07.23 01:17, Chris Johns wrote:
>> On 30/6/2023 4:26 pm, Sebastian Huber wrote:
>>> Hello,
>>>
>>> it seems the RTEMS 6.1 release is getting closer. We should think about the 
>>> tool
>>> versions for the release.
>>>
>>> For GCC, my preferred choice would be GCC 13.2:
>>>
>>> https://gcc.gnu.org/pipermail/gcc/2023-June/241838.html
>>>
>>> In GCC 12 a big change was enabling the vectorization support with -O2. This
>>> should have stabilized in GCC 13. GCC 13 contains some RTEMS-specific
>>> improvements for Ada.
>>>
>>> For Binutils and GDB I would just use the latest release available at the 
>>> RTEMS
>>> 6 branch point.
>>
>> If someone can please raise a ticket when the versions details have been 
>> decided
>> with the versions and assign to me I will update the RSB and test RSB from 
>> git
>> and RSB release builds.
> 
> I added a ticket for this:
> 
> https://devel.rtems.org/ticket/4921

Thanks. I have linked it to https://devel.rtems.org/ticket/4768.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Tool versions for RTEMS 6.1 release?

[Chris Johns]

On 30/6/2023 4:26 pm, Sebastian Huber wrote:
> Hello,
> 
> it seems the RTEMS 6.1 release is getting closer. We should think about the 
> tool
> versions for the release.
> 
> For GCC, my preferred choice would be GCC 13.2:
> 
> https://gcc.gnu.org/pipermail/gcc/2023-June/241838.html
> 
> In GCC 12 a big change was enabling the vectorization support with -O2. This
> should have stabilized in GCC 13. GCC 13 contains some RTEMS-specific
> improvements for Ada.
> 
> For Binutils and GDB I would just use the latest release available at the 
> RTEMS
> 6 branch point.

If someone can please raise a ticket when the versions details have been decided
with the versions and assign to me I will update the RSB and test RSB from git
and RSB release builds.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RSB 2/4] 6: Update GCC 10 and 12

[Chris Johns]

On 30/6/2023 4:20 pm, Sebastian Huber wrote:
> On 29.06.23 02:20, Chris Johns wrote:
>> On 28/6/2023 3:33 pm, Sebastian Huber wrote:
>>> On 28.06.23 04:37, Chris Johns wrote:
>>>> Can you please provide something other than update in the commit message?
>>>>
>>>> If it is to pick up patches on these gcc release branches then please say 
>>>> so.
>>>
>>> This update has no particular reason. I just had a bit of time to run my 
>>> update
>>> script. Ideally there would be an automatic update process in place. If you
>>> don't want to follow the upstream release branches, then please say so. 
>>> However,
>>> this work helps to identify RTEMS related issues in the upstream 
>>> development.
>>> Working tools for RTEMS need maintenance. It is not that release versions 
>>> of GCC
>>> magically work on RTEMS.
>>
>> This sounds great. Would it be possible to add a simple comment in the commit
>> message this is a housekeeping update to the latest? It makes it easier
>> reviewing the commit log to understand changes of interest verses such as 
>> things
>> we need or make in newlib verses housekeeping.
> 
> Ok, makes sense. I added this sentence:
> 
> Keep RTEMS up to date with the upstream development.
> 

Perfect and appreciated. It is now easier to review and accept a change like 
this.

>>>> Are these versions of the compiler tracking tarfile packages?
>>>
>>> No, the configurations track the release branches.
>>>
>>
>> For newlib this makes sense during development and releases because of 
>> newlib's
>> long release period. It also works for binutils, gcc and gdb when we are in
>> development however I am not sure it does with releases. Should we look to
>> tarfiles for releases for the binutils, gcc and gdb tools?
> 
> For RTEMS releases it makes sense to use upstream releases for the tools with 
> as
> few patches as possible.

Great. How do we make the move? I am happy to update the RSB if I am given the
details or instructions. I feel you are the best person to know when so if you
think it is OK to change does it work if you create a ticket with the links to
the sources then assign it to me?

Thanks
Chris

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 00/32] Integrate pre-qualified LEON3 BSP

[Chris Johns]

On 29/6/2023 3:41 am, Sebastian Huber wrote:
> On 16.06.23 08:00, Sebastian Huber wrote:
>> The register block specification were recently integrated in the RTEMS
>> Software Engineering manual.  Now it is time to integrate the
>> pre-qualified LEON3 BSP which uses the generated GRLIB header files.
>>
>> The existing tests in the RTEMS test suite are basically BSP
>> independent. This patch set introduces BSP-specific validation tests.
>> These tests are disabled for other BSPs through the build system, for
>> example:
>>
>> spec/build/testsuites/validation/bsp-sparc-leon3-gr712rc.yml
>> [...]
>> cxxflags: []
>> enabled-by: sparc/gr712rc
>> features: c cprogram
>> [...]
>>
>> The patch set introduces new header files for GRLIB in
>> "bsps/include/grlib".  These header files were generated from
>> specification items in:
>>
>> https://github.com/RTEMS/rtems-central/tree/master/spec/dev/grlib/if
>>
>> The specification was created using the GRIP reference manual
>> (https://www.gaisler.com/products/grlib/grip.pdf) and is quite complete.
>> The generated header files were reviewed by the ISVV activity which
>> resulted in two tickets:
>>
>> https://devel.rtems.org/ticket/4828
>>
>> https://devel.rtems.org/ticket/4842
>>
>> In the long term, the existing GRLIB header files should be replaced by
>> the generated header files. Using specification items for the register
>> blocks has the potential benefit that, in addition to the C header
>> files, files for C++/Rust/Python could be generated.
>>
>> The main change for the sparc/gr712rc and sparc/gr740 BSPs is the
>> removal of the dynamic device enumeration in favor of a static
>> initialization.  This greatly simplifies the specification and
>> validation of the BSP-specific parts. It also reduces the code and data
>> size for applications which do not need the dynamic device enumeration.
>>
>> v2:
>>
>> * Move BSP-specific tests to "testsuites/validation/bsps".
>>
>> * Rearrange patches so that they build individually.
> 
> Any comments to this patch set? For the leon3-specific parts I wait for a 
> review
> from Gaisler.

Nothing new from me.

I still do not see how the reg struct is verified however you are fine with
that. I do not use this code.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RSB 2/4] 6: Update GCC 10 and 12

[Chris Johns]

On 28/6/2023 3:33 pm, Sebastian Huber wrote:
> On 28.06.23 04:37, Chris Johns wrote:
>> Can you please provide something other than update in the commit message?
>>
>> If it is to pick up patches on these gcc release branches then please say so.
> 
> This update has no particular reason. I just had a bit of time to run my 
> update
> script. Ideally there would be an automatic update process in place. If you
> don't want to follow the upstream release branches, then please say so. 
> However,
> this work helps to identify RTEMS related issues in the upstream development.
> Working tools for RTEMS need maintenance. It is not that release versions of 
> GCC
> magically work on RTEMS.

This sounds great. Would it be possible to add a simple comment in the commit
message this is a housekeeping update to the latest? It makes it easier
reviewing the commit log to understand changes of interest verses such as things
we need or make in newlib verses housekeeping.

>>
>> Are these versions of the compiler tracking tarfile packages?
> 
> No, the configurations track the release branches.
> 

For newlib this makes sense during development and releases because of newlib's
long release period. It also works for binutils, gcc and gdb when we are in
development however I am not sure it does with releases. Should we look to
tarfiles for releases for the binutils, gcc and gdb tools?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RSB 1/4] 6/7: Update Newlib

[Chris Johns]

Hi,

What has changed in this version? Is there anything specific we need to know
about or need?

Thanks
Chris

On 27/6/2023 8:21 pm, Sebastian Huber wrote:
> ---
>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
>  rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> index 39b97a5..870c06f 100644
> --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> @@ -17,12 +17,12 @@
>  %patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
>  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
>  
> -%define newlib_version 9ae9eef
> +%define newlib_version 4c7d0df
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
> +  
> tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> index 84b5223..0eff966 100644
> --- a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> @@ -20,12 +20,12 @@
>  %patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
>  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
>  
> -%define newlib_version 9ae9eef
> +%define newlib_version 4c7d0df
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
> +  
> tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> index f4c47d4..2277b01 100644
> --- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> @@ -38,13 +38,13 @@
>  
> KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
>  # Comment above related to #4657 and patches ends here
>  
> -%define newlib_version 9ae9eef
> +%define newlib_version 4c7d0df
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \
> 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
> +  
> tA7iXyG/UwRDYmGIMd1iS5IjvM5+lL2E8l6ez+xi8vr9BBupECuWwoq1vzlIy4Uj7+dEzLKuepassKx9M4H21A==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> index d39a0b5..8bc72d1 100644
> --- a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> @@ -8,12 +8,12 @@
>  %hash sha512 %{gcc_expand_name}.tar.gz \
>
> E5KKObrZDIF1nEAFmZ6zGstL/VAPGCR+FIkCVW3akyTmAPITsmlaNErGHESHjG8PRmCO8zkCHkjkAv6MaHsWvQ==
>  
> -%define newlib_version 9ae9eef
> +%define newlib_version 4c7d0df
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> 

Re: [RSB 2/4] 6: Update GCC 10 and 12

[Chris Johns]

Can you please provide something other than update in the commit message?

If it is to pick up patches on these gcc release branches then please say so.

Are these versions of the compiler tracking tarfile packages?

Thanks
Chris

On 27/6/2023 8:21 pm, Sebastian Huber wrote:
> ---
>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 4 ++--
>  rtems/config/tools/rtems-gcc-12-newlib-head.cfg | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> index 870c06f..e01542e 100644
> --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> @@ -1,12 +1,12 @@
>  %include %{_configdir}/checks.cfg
>  %include %{_configdir}/base.cfg
>  
> -%define gcc_version 52c451e
> +%define gcc_version ab134ec
>  %define gcc_external 1
>  %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
>  %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
> https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
>  %hash sha512 %{gcc_expand_name}.tar.gz \
> -  
> qjkDEEGK9YmRSSz8sQfwgzy9xPkvcvDNbo68vEM92jAEyVmzbTskJW/MtEyw7hwzOJgjWJsdoMKdsUa0yOXlcw==
> +  
> UQEiEegns9qDLBk35p7lrIfeoG3pHOlCPVbnEUqnL3Cqa2yjzl9cc8dNXKUTSvwOeuCQqGN2x08greTe9ZTqaA==
>  
>  %patch add gcc -p1 
> https://devel.rtems.org/raw-attachment/ticket/4196/0001-Back-port-v8-of-gcov-improvements-to-GCC-10.patch
>  %hash sha512 0001-Back-port-v8-of-gcov-improvements-to-GCC-10.patch 
> c2d1faed68aa0f60bef917365545cc4cc899df428a5d08f178417c06def4fd3cd3a749c1871c8a22552022c29dfae4a3d21161e2b01291e458ea8d670f01887e
> diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> index 2277b01..7b0d4cb 100644
> --- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> @@ -1,12 +1,12 @@
>  %include %{_configdir}/checks.cfg
>  %include %{_configdir}/base.cfg
>  
> -%define gcc_version efc21f1
> +%define gcc_version 0f54a73
>  %define gcc_external 1
>  %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
>  %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
> https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
>  %hash sha512 %{gcc_expand_name}.tar.gz \
> -  
> KTiGNk2WdP/uwZS8t8L1uy0mwzBjrIIDkD/lZycGyGW9TII7dO//2sRF3jfw1drTOoM6+/bqpkDLp3k1/6TZvA==
> +  
> 6q/FCgcnONitGrUuXF9y8nx6FiiSL3JSFwDh31pdJem4QvvcP7pFnybdw/Ve1uOIHab38xZyFVbEsANdAZN6Sg==
>  
>  %patch add gcc -p1 
> https://devel.rtems.org/raw-attachment/ticket/4196/0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch
>  %hash sha512 0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch \
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] tester/rtems: add renode implementation

[Chris Johns]

I am as well

Chris

On 28/6/2023 12:25 am, Joel Sherrill wrote:
> I'm OK with this patch.
> 
> Is it assuming that you installed renode on your own -- not using the RSB?
> 
> --joel
> 
> On Mon, Jun 26, 2023 at 5:37 PM Muhammad Sulthan Mazaya
> mailto:msulthanmaz...@gmail.com>> wrote:
> 
> Hi Chris,
> 
> Yes they are the same. I thought there was an email error, so I re-send it
> twice.
> 
> On Tue, 27 Jun 2023, 07:46 Chris Johns,  <mailto:chr...@rtems.org>> wrote:
> 
> Hi Muhammad,
> 
> The patch looks good, thanks.
> 
> Are the 3 posted patches the same version?
> 
> Chris
> 
> On 26/6/2023 2:17 pm, Muhammad Sulthan Mazaya wrote:
> > Patch for the implementation of renode on rtems-test. Currently, 
> renode
> > installation has not been implemented in rsb. Thus, for testing, 
> you can
> > install renode by referring to the documentation link below.
> >
> > Downloads for debian, fedora, arch, macOS, and windows:
> > https://renode.io/#downloads <https://renode.io/#downloads>
> >
> > Alternatively, you can access Renode's GitHub releases:
> > https://github.com/renode/renode/releases/tag/v1.13.3
> <https://github.com/renode/renode/releases/tag/v1.13.3>
> >
> > You can also build it from source:
> >
> 
> https://renode.readthedocs.io/en/latest/advanced/building_from_sources.html#building-from-source
>  
> <https://renode.readthedocs.io/en/latest/advanced/building_from_sources.html#building-from-source>
> >
> > This patch consists of changes to test kendrytek210 using renode. To
> > test it, you can build the kendrytek210 test suite as instructed in 
> the
> > rtems-docs (Alan's patch here:
> https://lists.rtems.org/pipermail/devel/2023-April/074838.html
> <https://lists.rtems.org/pipermail/devel/2023-April/074838.html>).
> > Then, use the following command to run the test suite.
> >
> > rtems-test --rtems-bsp=kendrytek210-renode [test-suite-path]
> >
> > ---
> >  .../testing/bsps/kendrytek210-renode.ini      | 38 +++
> >  tester/rtems/testing/renode.cfg               | 64 
> +++
> >  .../testing/renode_scripts/kendrytek210.resc  | 53 +++
> >  3 files changed, 155 insertions(+)
> >  create mode 100644 
> tester/rtems/testing/bsps/kendrytek210-renode.ini
> >  create mode 100644 tester/rtems/testing/renode.cfg
> >  create mode 100644 
> tester/rtems/testing/renode_scripts/kendrytek210.resc
> >
> > diff --git a/tester/rtems/testing/bsps/kendrytek210-renode.ini
> b/tester/rtems/testing/bsps/kendrytek210-renode.ini
> > new file mode 100644
> > index 000..95850c5
> > --- /dev/null
> > +++ b/tester/rtems/testing/bsps/kendrytek210-renode.ini
> > @@ -0,0 +1,38 @@
> > +#
> > +# RTEMS Tools Project (http://www.rtems.org/ 
> <http://www.rtems.org/>)
> > +# Copyright 2010-2014 Chris Johns (chr...@rtems.org
> <mailto:chr...@rtems.org>)
> > +# All rights reserved.
> > +#
> > +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> > +#
> > +# Redistribution and use in source and binary forms, with or 
> without
> > +# modification, are permitted provided that the following 
> conditions
> are met:
> > +#
> > +# 1. Redistributions of source code must retain the above copyright
> notice,
> > +# this list of conditions and the following disclaimer.
> > +#
> > +# 2. Redistributions in binary form must reproduce the above
> copyright notice,
> > +# this list of conditions and the following disclaimer in the
> documentation
> > +# and/or other materials provided with the distribution.
> > +#
> > +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 
> CONTRIBUTORS
> "AS IS"
> > +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> > +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 
> PARTICULAR
> PURPOSE
> > +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
> 

Re: [PATCH rtems-libbsd] freebsd/if_cgem: Remove QEMU workaround

[Chris Johns]

This looks good.

Thanks
Chris

On 28/6/2023 1:30 am, Kinsey Moore wrote:
> Note that this patch is for 6-freebsd-12 and its removal reduces the burden to
> make the master branch match functionality.
> 
> On Tue, Jun 27, 2023 at 10:28 AM Kinsey Moore  > wrote:
> 
> This removes the workaround applied on the fly for QEMU that disables
> priority queueing. The priority queue interrupt was not previously
> hooked up properly in QEMU and RSB now has the patches to allow it to
> work.
> ---
>  freebsd/sys/dev/cadence/if_cgem.c | 26 +++---
>  1 file changed, 7 insertions(+), 19 deletions(-)
> 
> diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> b/freebsd/sys/dev/cadence/if_cgem.c
> index 689c3611..c1c88e77 100644
> --- a/freebsd/sys/dev/cadence/if_cgem.c
> +++ b/freebsd/sys/dev/cadence/if_cgem.c
> @@ -133,7 +133,6 @@ struct cgem_softc {
>         uint32_t                net_ctl_shadow;
>  #ifdef __rtems__
>         uint32_t                net_cfg_shadow;
> -       int                     neednullqs;
>         int                     phy_contype;
>  #endif /* __rtems__ */
>         int                     ref_clk_num;
> @@ -458,9 +457,8 @@ cgem_setup_descs(struct cgem_softc *sc)
>         int desc_rings_size = CGEM_NUM_RX_DESCS * sizeof(struct 
> cgem_rx_desc) +
>             CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
> 
> -       if (sc->neednullqs)
> -               desc_rings_size += sizeof(struct cgem_rx_desc) +
> -                   sizeof(struct cgem_tx_desc);
> +       desc_rings_size += sizeof(struct cgem_rx_desc) +
> +           sizeof(struct cgem_tx_desc);
>  #endif /* __rtems__ */
>         sc->txring = NULL;
>         sc->rxring = NULL;
> @@ -609,13 +607,11 @@ cgem_setup_descs(struct cgem_softc *sc)
>         sc->txring_queued = 0;
> 
>  #ifdef __rtems__
> -       if (sc->neednullqs) {
> -               sc->null_qs = (void *)(sc->txring + CGEM_NUM_TX_DESCS);
> -               sc->null_qs_physaddr = sc->txring_physaddr +
> -                   CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
> +       sc->null_qs = (void *)(sc->txring + CGEM_NUM_TX_DESCS);
> +       sc->null_qs_physaddr = sc->txring_physaddr +
> +           CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
> 
> -               cgem_null_qs(sc);
> -       }
> +       cgem_null_qs(sc);
>  #endif /* __rtems__ */
> 
>         return (0);
> @@ -2074,15 +2070,7 @@ cgem_attach(device_t dev)
> 
>         sc->if_old_flags = if_getflags(ifp);
>         sc->rxbufs = DEFAULT_NUM_RX_BUFS;
> -#if defined(CGEM64) && defined(__rtems__)
> -       uint32_t design_cfg6 = RD4(sc, CGEM_DESIGN_CFG6);
> -       /*
> -        * QEMU does not have PBUF_CUTTHRU defined and is broken when 
> trying
> -        * to use nullqs
> -        */
> -       if ((design_cfg6 & CGEM_DESIGN_CFG6_PBUF_CUTTHRU))
> -               sc->neednullqs = 1;
> -#else
> +#if !defined(CGEM64) && defined(__rtems__)
>         sc->rxhangwar = 1;
>  #endif
> 
> -- 
> 2.30.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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Initializing I2C on the RTEMS6 MVME3100 BSP

[Chris Johns]

On 28/6/2023 6:48 am, Zainab Olalekan wrote:
> I am encountering difficulties with initializing I2C on the RTEMS6 MVME3100 
> BSP,
> required to run EPICS test. I have made adaptations based on Heinz's patch for
> RTEMS5, but I am experiencing an error. Here is the specific error message
> alongside an attached file showing the modifications made.

The trace shows the code is crashing somewhere.

Has Heinz run I2C on the MVME3100?

We now have an #epics channel on our discord server
(https://devel.rtems.org/wiki/Developer/discord) which can be more interactive
depending on timezones.

Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: [PATCH rtems-docs] c-user: Update references to rtems_task_wake_after

[Chris Johns]

On 28/6/2023 7:37 am, Kinsey Moore wrote:
> 
> On Tue, Jun 27, 2023 at 4:05 PM Sebastian Huber
>  >
> wrote:
> 
> On 27.06.23 22:18, Kinsey Moore wrote:
> > diff --git a/c-user/task/directives.rst b/c-user/task/directives.rst
> > index c082b51..3334679 100644
> > --- a/c-user/task/directives.rst
> > +++ b/c-user/task/directives.rst
> > @@ -1475,15 +1475,15 @@ The following constraints apply to this 
> directive:
> >       \clearpage
> >   
> >   .. index:: rtems_task_wake_after()
> > -.. index:: delay a task for an interval
> > -.. index:: wake up after an interval
> > +.. index:: delay a task for a number of ticks
> > +.. index:: wake up after a number of ticks
> >   
> >   .. _InterfaceRtemsTaskWakeAfter:
> >   
> >   rtems_task_wake_after()
> >   ---
> >   
> > -Wakes up after an interval in :term:`clock ticks ` or 
> yields the
> > +Wakes up after a number of :term:`clock ticks ` or yields 
> the
> >   processor.
> >   
> >   .. rubric:: CALLING SEQUENCE:
> > @@ -1502,10 +1502,12 @@ processor.
> >   
> >   This directive blocks the calling task for the specified ``ticks`` of 
> clock
> >   ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`. 
> When the
> > -requested interval has elapsed, the task is made ready.  The clock tick
> > +requested number of ticks has elapsed, the task is made ready.  The 
> clock
> tick
> >   directives automatically updates the delay period.  The calling task 
> may
> give
> >   up the processor and remain in the ready state by specifying a value 
> of
> > -:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.
> > +:c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.  Applications requiring
> use of a
> > +time base instead of system ticks should make use of ``nanosleep()`` or
> > +``clock_nanosleep()``.
> 
> What is a time base?
> 
> 
> A delay specified in some subunit of seconds instead of clock ticks.
> 
> 
> nanosleep() has the same issues as rtems_task_wake_after(). If you want
> to wait for fixed intervals, then you have to use clock_nanosleep() with
> TIMER_ABSTIME and CLOCK_MONOTONIC.
> 
> The wording with the interval is not really wrong. Only the clock
> resolution is a bit coarse (clock ticks). I guess the real problem is
> that if you want to implement a periodic task with
> 
> while (1) {
>         f();
>         rtems_task_wake_after(period);
> }
> 
> then this doesn't work if the time between calls to
> rtems_task_wake_after() varies within the range of clock ticks. This can
> be fixed by using clock_nanosleep() with TIMER_ABSTIME and 
> CLOCK_MONOTONIC.
> 
> 
> The issue with specifying "interval" is that "time interval" is a common 
> phrase
> in general and a clock tick can vary depending on application configuration.
> While the use of "interval" isn't necessarily wrong, "time interval" is very
> misleading in this context and could easily be assumed. Would "clock tick
> interval" be reasonable for clarity as a way to distance the verbiage from 
> "time
> interval"?

The key issue is the use of language such as:

  ticks

This parameter is the interval in clock ticks to delay the
task or RTEMS_YIELD_PROCESSOR to yield the processor.

The task may not be delayed by the interval in clock ticks. The interference of
this language is the task is delayed by the period of a clock tick multiplied by
the interval. The task is delayed an indeterminate period of time because the
period of time from the call to the next tick is considered a "tick interval"
when it is only part of a tick interval. Better wording maybe:

 ticks

This parameter is a count of clock ticks to delay the
task or RTEMS_YIELD_PROCESSOR to yield the processor.

This may seem apparent to some but it seems not to others and what we have
documented is taken at face value.

This came to light when testing RTEMS 5 and EPICS 7 when the EPICS
systemTickTest test was run. The issue tracking this is:

https://gitlab.com/nsf-noirlab/gemini/rtsw/epics-base/epics-base/-/issues/30

A contributing factor is the improved timestamps introduced in RTEMS 5.

We need to document the fact users need to +1 to the interval if their usage is
the task needs to sleep for a period no shorter then the internal, ie internal x
clock_tick_period.

The test code shows clock_nanosleep() does the right thing and determines if the
remaining period until then next tick is shorter than the requested period and
if not the sleep is extended to the next tick.

To observe how this gets confusing, RTEMS 4.x + EPICS 7 is using the classic API
for epicsThreadSleep:

https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/src/osi/os/RTEMS-score/osdThread.c#L494

and RTEMS 5,6 + EPICS 7 is using POSIX which is:

Re: [PATCH] cpukit/flash: Correct erase ioctl address

[Chris Johns]

Pushed and thanks

Chris

On 26/6/2023 3:29 pm, aaron.nyh...@unfoldedeffective.com wrote:
> From: Aaron Nyholm 
> 
> Previously, the erase ioctl call would ignore flash regions and erase at
> the absolute address passed in. This adds a check for if the region is
> set and adds the region offset accordingly.
> ---
>  cpukit/dev/flash/flashdev.c | 43 ++---
>  1 file changed, 35 insertions(+), 8 deletions(-)
> 
> diff --git a/cpukit/dev/flash/flashdev.c b/cpukit/dev/flash/flashdev.c
> index 4b7a0560ff..be85593201 100644
> --- a/cpukit/dev/flash/flashdev.c
> +++ b/cpukit/dev/flash/flashdev.c
> @@ -135,6 +135,13 @@ static int rtems_flashdev_get_addr(
>off_t *addr
>  );
>  
> +static int rtems_flashdev_get_abs_addr(
> +  rtems_flashdev *flash,
> +  rtems_libio_t *iop,
> +  size_t count,
> +  off_t *addr
> +);
> +
>  static int rtems_flashdev_update_and_return(
>rtems_libio_t *iop,
>int status,
> @@ -565,6 +572,28 @@ static int rtems_flashdev_get_addr(
>return 0;
>  }
>  
> +static int rtems_flashdev_get_abs_addr(
> +  rtems_flashdev *flash,
> +  rtems_libio_t *iop,
> +  size_t count,
> +  off_t *addr
> +)
> +{
> +  off_t new_offset;
> +
> +  /* Check address is in valid region */
> +  new_offset = *addr + count;
> +
> +  if (rtems_flashdev_check_offset_region(flash, iop, new_offset)) {
> +return -1;
> +  }
> +
> +  /* Get address for operation */
> +  if ( rtems_flashdev_is_region_defined( iop ) ) {
> +*addr = ( *addr + rtems_flashdev_get_region_offset( flash, iop ) );
> +  }
> +  return 0;
> +}
>  static int rtems_flashdev_update_and_return(
>rtems_libio_t *iop,
>int status,
> @@ -588,7 +617,7 @@ static int rtems_flashdev_ioctl_erase(
>  )
>  {
>rtems_flashdev_region *erase_args_1;
> -  off_t check_offset;
> +  off_t new_offset;
>int status;
>  
>if ( flash->erase == NULL ) {
> @@ -597,16 +626,14 @@ static int rtems_flashdev_ioctl_erase(
>  
>erase_args_1 = (rtems_flashdev_region *) arg;
>/* Check erasing valid region */
> -  check_offset = erase_args_1->offset + erase_args_1->size;
> -  if ( rtems_flashdev_is_region_defined( iop ) && (
> - rtems_flashdev_check_offset_region(flash, iop, check_offset) ||
> - ( erase_args_1->offset <
> -   rtems_flashdev_get_region_offset( flash, iop ) ) ) ) {
> -rtems_set_errno_and_return_minus_one( EINVAL );
> +  new_offset = erase_args_1->offset;
> +  status = rtems_flashdev_get_abs_addr(flash, iop, erase_args_1->size, 
> _offset);
> +  if ( status < 0 ) {
> +return status;
>}
>  
>/* Erase flash */
> -  status = ( *flash->erase )( flash, erase_args_1->offset, 
> erase_args_1->size );
> +  status = ( *flash->erase )( flash, new_offset, erase_args_1->size );
>return status;
>  }
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] qemu-5-1: Update to the latest CGEM patch

[Chris Johns]

On 27/6/2023 5:02 am, Kinsey Moore wrote:
> The original version of this patch had a conflict between the two
> interrupts where the program-viewable interrupt state could be
> deasserted when it should have been asserted. The new version of this
> patch resolves that conflict.
> ---
>  source-builder/config/qemu-5-1.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/source-builder/config/qemu-5-1.cfg 
> b/source-builder/config/qemu-5-1.cfg
> index 4b2951d..409ed89 100644
> --- a/source-builder/config/qemu-5-1.cfg
> +++ b/source-builder/config/qemu-5-1.cfg
> @@ -8,6 +8,6 @@
>  
>  %include %{_configdir}/qemu-common-2.cfg
>  
> -%patch add qemu --rsb-file=cgem_zynqmp_versal.patch -p1 
> https://devel.rtems.org/raw-attachment/ticket/4919/cgem_zynqmp_versal.patch
> +%patch add qemu --rsb-file=cgem_zynqmp_versal.patch -p1 
> https://devel.rtems.org/raw-attachment/ticket/4919/0001-hw-arm-xlnx-Connect-secondary-CGEM-IRQs.patch
>  %hash sha512 cgem_zynqmp_versal.patch \
> -  
> 2a4a894acefd00a76f48b6d6339696c8c53ece8e044687cb86c268840eac226d251fe89af933db4c20f5f07a3faff92c7c28c4c82b0617e4b200fd0895ac6158
> +  
> 5c80060f6f506b8b9a10a8a3dd3621d4725425beebf598d95e5d7db77564fbcba5786d8eeccd7182a99e03ace842af860ab70c468271a95e249e245aa4b81945

Please use a base64 SHA512 hash. The source-builder/sha512-base64 command will
generate the hash for you.

A base64 hash version is ok to push.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] tester/rtems: add renode implementation

[Chris Johns]

Hi Muhammad,

The patch looks good, thanks.

Are the 3 posted patches the same version?

Chris

On 26/6/2023 2:17 pm, Muhammad Sulthan Mazaya wrote:
> Patch for the implementation of renode on rtems-test. Currently, renode
> installation has not been implemented in rsb. Thus, for testing, you can
> install renode by referring to the documentation link below.
> 
> Downloads for debian, fedora, arch, macOS, and windows:
> https://renode.io/#downloads
> 
> Alternatively, you can access Renode's GitHub releases:
> https://github.com/renode/renode/releases/tag/v1.13.3
> 
> You can also build it from source:
> https://renode.readthedocs.io/en/latest/advanced/building_from_sources.html#building-from-source
> 
> This patch consists of changes to test kendrytek210 using renode. To
> test it, you can build the kendrytek210 test suite as instructed in the
> rtems-docs (Alan's patch here: 
> https://lists.rtems.org/pipermail/devel/2023-April/074838.html).
> Then, use the following command to run the test suite.
> 
> rtems-test --rtems-bsp=kendrytek210-renode [test-suite-path]
> 
> ---
>  .../testing/bsps/kendrytek210-renode.ini  | 38 +++
>  tester/rtems/testing/renode.cfg   | 64 +++
>  .../testing/renode_scripts/kendrytek210.resc  | 53 +++
>  3 files changed, 155 insertions(+)
>  create mode 100644 tester/rtems/testing/bsps/kendrytek210-renode.ini
>  create mode 100644 tester/rtems/testing/renode.cfg
>  create mode 100644 tester/rtems/testing/renode_scripts/kendrytek210.resc
> 
> diff --git a/tester/rtems/testing/bsps/kendrytek210-renode.ini 
> b/tester/rtems/testing/bsps/kendrytek210-renode.ini
> new file mode 100644
> index 000..95850c5
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/kendrytek210-renode.ini
> @@ -0,0 +1,38 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2010-2014 Chris Johns (chr...@rtems.org)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are met:
> +#
> +# 1. Redistributions of source code must retain the above copyright notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright 
> notice,
> +# this list of conditions and the following disclaimer in the documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> +# POSSIBILITY OF SUCH DAMAGE.
> +#
> +
> +#
> +# The Kendrytek210 Renode BSP
> +#
> +[kendrytek210-renode]
> +bsp = kendrytek210-renode
> +arch= riscv
> +tester  = %{_rtscripts}/renode.cfg
> +bsp_resc_script = %{_rtscripts}/renode_scripts/kendrytek210.resc
> diff --git a/tester/rtems/testing/renode.cfg b/tester/rtems/testing/renode.cfg
> new file mode 100644
> index 000..49e84a5
> --- /dev/null
> +++ b/tester/rtems/testing/renode.cfg
> @@ -0,0 +1,64 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2010-2014 Chris Johns (chr...@rtems.org)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are met:
> +#
> +# 1. Redistributions of source code must retain the above copyright notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright 
> notice,
> +# this list of conditions and the following disclaimer in the documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> +# AND ANY EXPRESS O

Re: [RBW] Plush old 531 steel frames (was being precious)

[JohnS]

Thank you Eric,

JohnS

On Sunday, June 25, 2023 at 11:14:27 AM UTC-4 campyo...@me.com wrote:

> The mount I added to the Singer is this one:
>
> [image: 
> 3198yXsC3ML._SR600,315_PIWhiteStrip,BottomLeft,0,35_PIStarRatingTHREEANDHALF,BottomLeft,360,-6_SR600,315_ZA321,445,290,400,400,AmazonEmberBold,12,4,0,0,5_SCLZZZ_FMpng_BG255,255,255.jpg]
>
> Elite 0123301 VIP Cage Clamps Water Bottle Cage, 25mm-70mm, Black 
> <https://www.amazon.com/Elite-0123301-Clamps-Bottle-25mm-70mm/dp/B00OS6HKIM/ref=asc_df_B00OS6HKIM/?tag=hyprod-20=df0=241987970787==g=8490519446908074857c===1014208=pla-355337713622=1>
> amazon.com 
> <https://www.amazon.com/Elite-0123301-Clamps-Bottle-25mm-70mm/dp/B00OS6HKIM/ref=asc_df_B00OS6HKIM/?tag=hyprod-20=df0=241987970787==g=8490519446908074857c===1014208=pla-355337713622=1>
>
> <https://www.amazon.com/Elite-0123301-Clamps-Bottle-25mm-70mm/dp/B00OS6HKIM/ref=asc_df_B00OS6HKIM/?tag=hyprod-20=df0=241987970787==g=8490519446908074857c===1014208=pla-355337713622=1>
>
> It’s been solid and dependable. The device adds mounting points—you 
> provide the bottle cage.
>
> --Eric Norris
> campyo...@me.com
> Insta: @CampyOnlyGuy
> YouTube: YouTube.com/CampyOnlyGuy 
>
> On Jun 24, 2023, at 9:16 AM, JohnS  wrote:
>
> Hello Eric N,
>
> Thanks for the close up of your bike. Because of it I noticed the clamped 
> on water bottle cage on the seat tube. Do you like? Which brand is it? I 
> would like to add a water bottle cage to my '82 Sequoia's down tube (Tange 
> Special Series Touring, Cro-Mo Double Butted), great riding bike, so much 
> more lively than my Surly Pacer.
>
> JohnS
>
> On Friday, June 23, 2023 at 11:57:10 PM UTC-4 campyo...@me.com wrote:
>
>> For the tubing nerds out there: the 531 Professional decal (in French) on 
>> my 1983 Alex Singer. 
>>
>> [image: image0.jpeg][image: image1.jpeg]
>>
>> –Eric N
>>
>>
>> On Jun 23, 2023, at 6:53 PM, brendonoid  wrote:
>>
>> 
>>
>> My late 80s Holdsworth Mistral is 531c (I assume that's the competition 
>> tubing?) And is the only frame I've ridden that has that "planing" feeling 
>> that Jan gets so hot under the collar for.
>> I have converted it to 650b and it is my go to roadish bike when I'm not 
>> on a Riv. Definitely a special frame.
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "RBW Owners Bunch" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to rbw-owners-bun...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/rbw-owners-bunch/ecb96a83-26c1-441a-b476-5ebd91747717n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/rbw-owners-bunch/ecb96a83-26c1-441a-b476-5ebd91747717n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rbw-owners-bun...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/rbw-owners-bunch/ce3db0a8-9f91-4d1f-a3d9-0d84e87a9b6cn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/rbw-owners-bunch/ce3db0a8-9f91-4d1f-a3d9-0d84e87a9b6cn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/4d824b31-75fc-4d8c-a24c-b3886126d94cn%40googlegroups.com.

Re: [RBW] Plush old 531 steel frames (was being precious)

[JohnS]

Hello Eric N,

Thanks for the close up of your bike. Because of it I noticed the clamped 
on water bottle cage on the seat tube. Do you like? Which brand is it? I 
would like to add a water bottle cage to my '82 Sequoia's down tube (Tange 
Special Series Touring, Cro-Mo Double Butted), great riding bike, so much 
more lively than my Surly Pacer.

JohnS

On Friday, June 23, 2023 at 11:57:10 PM UTC-4 campyo...@me.com wrote:

> For the tubing nerds out there: the 531 Professional decal (in French) on 
> my 1983 Alex Singer. 
>
> [image: image0.jpeg][image: image1.jpeg]
>
> –Eric N
>
>
> On Jun 23, 2023, at 6:53 PM, brendonoid  wrote:
>
> 
>
> My late 80s Holdsworth Mistral is 531c (I assume that's the competition 
> tubing?) And is the only frame I've ridden that has that "planing" feeling 
> that Jan gets so hot under the collar for.
> I have converted it to 650b and it is my go to roadish bike when I'm not 
> on a Riv. Definitely a special frame.
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rbw-owners-bun...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/rbw-owners-bunch/ecb96a83-26c1-441a-b476-5ebd91747717n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/rbw-owners-bunch/ecb96a83-26c1-441a-b476-5ebd91747717n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/ce3db0a8-9f91-4d1f-a3d9-0d84e87a9b6cn%40googlegroups.com.

Re: [PATCH] bsps/xqspipsu: Handle SMP systems properly

[Chris Johns]

OK

Chris

On 22/6/2023 2:09 am, Kinsey Moore wrote:
> The NOR driver was not written with SMP systems and caching in mind.
> This makes the IsBusy flag volatile for updates across cores and
> introduces cache flushing and invalidation where necessary for data
> manipulated by the DMA engine in the QSPI peripheral.
> ---
>  bsps/include/dev/spi/xqspipsu.h |  3 +++
>  bsps/shared/dev/spi/xqspipsu-flash-helper.c |  3 +++
>  bsps/shared/dev/spi/xqspipsu.c  | 23 +
>  3 files changed, 29 insertions(+)
> 
> diff --git a/bsps/include/dev/spi/xqspipsu.h b/bsps/include/dev/spi/xqspipsu.h
> index 7d9b662464..92d38eb0c8 100644
> --- a/bsps/include/dev/spi/xqspipsu.h
> +++ b/bsps/include/dev/spi/xqspipsu.h
> @@ -259,6 +259,9 @@ typedef struct {
>   s32 TxBytes; /**< Number of bytes to transfer (state) */
>   s32 RxBytes; /**< Number of bytes left to transfer(state) */
>   s32 GenFifoEntries;  /**< Number of Gen FIFO entries remaining */
> +#ifdef __rtems__
> + volatile
> +#endif
>   u32 IsBusy;  /**< A transfer is in progress (state) */
>   u32 ReadMode;/**< DMA or IO mode */
>   u32 GenFifoCS;  /**< Gen FIFO chip selection */
> diff --git a/bsps/shared/dev/spi/xqspipsu-flash-helper.c 
> b/bsps/shared/dev/spi/xqspipsu-flash-helper.c
> index 4e018bf2fa..c9d8273b87 100644
> --- a/bsps/shared/dev/spi/xqspipsu-flash-helper.c
> +++ b/bsps/shared/dev/spi/xqspipsu-flash-helper.c
> @@ -314,6 +314,7 @@ static int FlashReadID(XQspiPsu *QspiPsuPtr)
>}
>while (TransferInProgress);
>  
> +  rtems_cache_invalidate_multiple_data_lines(ReadBfrPtr, 3);
>/* In case of dual, read both and ensure they are same make/size */
>  
>/*
> @@ -860,6 +861,7 @@ int QspiPsu_NOR_Read(
>  while (TransferInProgress);
>  
>}
> +  rtems_cache_invalidate_multiple_data_lines(ReadBuffer, ByteCount);
>return 0;
>  }
>  
> @@ -1047,6 +1049,7 @@ static int MultiDieRead(
>  Address += data_len;
>  remain_len -= data_len;
>}
> +  rtems_cache_invalidate_multiple_data_lines(ReadBfrPtr, ByteCount);
>return 0;
>  }
>  
> diff --git a/bsps/shared/dev/spi/xqspipsu.c b/bsps/shared/dev/spi/xqspipsu.c
> index 1286efd359..c77407bdf4 100644
> --- a/bsps/shared/dev/spi/xqspipsu.c
> +++ b/bsps/shared/dev/spi/xqspipsu.c
> @@ -84,6 +84,9 @@
>  #include "xqspipsu.h"
>  #include "xqspipsu_control.h"
>  #include "sleep.h"
> +#ifdef __rtems__
> +#include 
> +#endif
>  
>  /** Constant Definitions 
> */
>  #define MAX_DELAY_CNT1000U   /**< Max delay count */
> @@ -442,7 +445,16 @@ s32 XQspiPsu_PolledTransfer(XQspiPsu *InstancePtr, 
> XQspiPsu_Msg *Msg,
>  
>   for (Index = 0; Index < (s32)NumMsg; Index++) {
>   Xil_AssertNonvoid(Msg[Index].ByteCount > 0U);
> +#ifdef __rtems__
> + if (Msg[Index].TxBfrPtr != NULL) {
> + 
> rtems_cache_flush_multiple_data_lines(Msg[Index].TxBfrPtr, 
> Msg[Index].ByteCount);
> + }
> +#endif
>   }
> +#ifdef __rtems__
> + rtems_cache_flush_multiple_data_lines(Msg, NumMsg * sizeof(*Msg));
> +#endif
> +
>   /*
>* Check whether there is another transfer in progress.
>* Not thread-safe
> @@ -582,7 +594,18 @@ s32 XQspiPsu_InterruptTransfer(XQspiPsu *InstancePtr, 
> XQspiPsu_Msg *Msg,
>   Xil_AssertNonvoid(InstancePtr->IsReady == XIL_COMPONENT_IS_READY);
>  
>   for (Index = 0; Index < (s32)NumMsg; Index++)
> +#ifdef __rtems__
> + {
> +#endif
>   Xil_AssertNonvoid(Msg[Index].ByteCount > 0U);
> +#ifdef __rtems__
> + if (Msg[Index].TxBfrPtr != NULL) {
> + 
> rtems_cache_flush_multiple_data_lines(Msg[Index].TxBfrPtr, 
> Msg[Index].ByteCount);
> + }
> + }
> + rtems_cache_flush_multiple_data_lines(Msg, NumMsg * sizeof(*Msg));
> +#endif
> +
>   /*
>* Check whether there is another transfer in progress.
>* Not thread-safe
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] rtemstoolkit: Fix shlex.split to use posix mode and add unit test for pipe operation

[Chris Johns]

On 21/6/2023 2:22 pm, Muhammad Sulthan Mazaya wrote:
>> On 21/6/2023 11:55 am, Muhammad Sulthan Mazaya wrote:
>> > Turns out subprocess.Popen operates on posix mode.
>>
>> Is this true for non-POSIX systems?
>>
>> Where is this documented?
> 
> It's not, turns out it is also dependent on the system too. It is documented
> here https://docs.python.org/3/library/subprocess.html#subprocess.Popen
> . Should I
> add a check like this instead?

I think this is more important:

https://docs.python.org/3/library/shlex.html

I think removing `posix=` from the argument as in your first patch makes our
command parsing conform to POSIX and that seems like a good thing for us.

I will apply the first patch.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] rtemstoolkit: Fix shlex.split to use posix mode and add unit test for pipe operation

[Chris Johns]

On 21/6/2023 11:55 am, Muhammad Sulthan Mazaya wrote:
> Turns out subprocess.Popen operates on posix mode. 

Is this true for non-POSIX systems?

Where is this documented?

Chris

Also, there is an
> issue with previous implementation of pipe command that is fixed by
> Chris. Now, it can also accepts command in form of a string. The unit
> test for that is added via this patch.
> 
> ---
>  rtemstoolkit/execute.py | 21 ++---
>  tester/rt/config.py |  2 +-
>  2 files changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/rtemstoolkit/execute.py b/rtemstoolkit/execute.py
> index e47aa24..3b7dcb0 100755
> --- a/rtemstoolkit/execute.py
> +++ b/rtemstoolkit/execute.py
> @@ -392,7 +392,7 @@ class execute(object):
>  command[0] = command[0] + '.exe'
>  # If a string split
>  if isinstance(command, str):
> -command = shlex.split(command, posix=False)
> +command = shlex.split(command)
>  # See if there is a pipe operator in the command. If present
>  # split the commands by the pipe and run them with the pipe.
>  # if no pipe it is the normal stdin and stdout
> @@ -623,10 +623,11 @@ if __name__ == "__main__":
>  proc.stdin.close()
>  e.capture(proc)
>  del proc
> -ec, proc = e.open(commands['open'])
> -if ec == 0:
> -e.capture(proc)
> -del proc
> +for c in commands['open']:
> +ec, proc = e.open(c)
> +if ec == 0:
> +e.capture(proc)
> +del proc
>  
>  def capture_output(text):
>  print(text, end = '')
> @@ -645,7 +646,10 @@ if __name__ == "__main__":
>  commands['windows']['csubsts'] = [('netstat %0', ['-a']),
>('netstat %0 %1', ['-a', '-n'])]
>  commands['windows']['pipe'] = ('ftp', None, 'help\nquit')
> -commands['windows']['open'] = ["echo",  "hello rtems", "|", "findstr", 
> "rtems"]
> +commands['windows']['open'] = [
> +["echo",  "hello rtems", "|", "findstr", "rtems"],
> +" ".join(["echo",  "hello rtems", "|", "findstr", "rtems"])
> +]
>  commands['unix']['shell'] = ['pwd', 'ls -las', './xyz', sh_shell_test]
>  commands['unix']['spawn'] = ['ls', 'execute.pyc', ['ls', '-i']]
>  commands['unix']['cmd'] = [('date'), ('date', '-R'), ('date', ['-u', 
> '+%d %D']),
> @@ -653,7 +657,10 @@ if __name__ == "__main__":
>  commands['unix']['csubsts'] = [('date %0 "+%d %D %S"', ['-u']),
> ('date %0 %1', ['-u', '+%d %D %S'])]
>  commands['unix']['pipe'] = ('grep', 'hello', 'hello world')
> -commands['unix']['open'] = ["echo", "hello world", "|", "cut", "-d ", 
> "-f2"]
> +commands['unix']['open'] = [
> +["echo", "hello world", "|", "cut", "-d ", "-f2"],
> +" ".join(["echo", "hello world", "|", "cut", "-d\" \"", "-f2"])
> +]
>  
>  print(arg_list('cmd a1 a2 "a3 is a string" a4'))
>  print(arg_list('cmd b1 b2 "b3 is a string a4'))
> diff --git a/tester/rt/config.py b/tester/rt/config.py
> index c0c31de..3b12c6c 100644
> --- a/tester/rt/config.py
> +++ b/tester/rt/config.py
> @@ -327,7 +327,7 @@ class file(config.file):
>  if len(_data):
>  ds = [_data[0]]
>  if len(_data) > 1:
> -ds += shlex.split(_data[1], posix=False)
> +ds += shlex.split(_data[1])
>  ds = self.expand(ds)
>  
>  if _directive == '%console':
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] tester/rt: use shlex.split to split command args

[Chris Johns]

Pushed

Thanks
Chris

On 20/6/2023 8:47 am, Muhammad Sulthan Mazaya wrote:
> The regular split-by-space function used to split command arguments
> creates compatibility issues with many shell command syntaxes. A
> specific example is the handling of string arguments, as shown below:
> 
> %define renode_args -e start_opts -e "s %{bsp_resc_script}"
> 
> Thus, it is changed to use shlex.split instead. It splits
> the command arguments using shell-like syntax. More about shlex
> module here: https://docs.python.org/3/library/shlex.html
> 
> ---
>  tester/rt/config.py | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tester/rt/config.py b/tester/rt/config.py
> index 8a433af..bf6fdbf 100644
> --- a/tester/rt/config.py
> +++ b/tester/rt/config.py
> @@ -38,6 +38,7 @@ import datetime
>  import os
>  import re
>  import threading
> +import shlex
>  
>  from rtemstoolkit import configuration
>  from rtemstoolkit import config
> @@ -326,7 +327,7 @@ class file(config.file):
>  if len(_data):
>  ds = [_data[0]]
>  if len(_data) > 1:
> -ds += _data[1].split()
> +ds += shlex.split(_data[1], posix=False)
>  ds = self.expand(ds)
>  
>  if _directive == '%console':
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools v2] rtemstoolkit: add support for executing pipe command

[Chris Johns]

Hi,

I applied the patch and ran the unit tests and they passed however the change
has broken the execute class.

The FreeBSD host runs sysctl to detect the number of cores when options are
loaded and the `e.shell()` at the top of `freebsd.py` is failing with:

$ ./tester/rtems-test --help
s: /: Permission denied
rtems-test: [options] [args]
RTEMS Tools Project, 6 (60e793a17c38)

The issue is the `command` can be a string or it can be a list and your change
assumes the command provided is a string.

Splitting the command if a string helped but a further changed was needed if
there is only 1 process to run so the stdin and stdout are set correctly.

I have fixed the code and pushed it so please review for me.

Thanks
Chris

On 20/6/2023 12:32 pm, Muhammad Sulthan Mazaya wrote:
> added unit tests and shorten long lines.
> 
> ---
>  rtemstoolkit/execute.py | 43 -
>  1 file changed, 38 insertions(+), 5 deletions(-)
> 
> diff --git a/rtemstoolkit/execute.py b/rtemstoolkit/execute.py
> index ed81589..9ec1cd7 100755
> --- a/rtemstoolkit/execute.py
> +++ b/rtemstoolkit/execute.py
> @@ -389,11 +389,38 @@ class execute(object):
>  r, e = os.path.splitext(command[0])
>  if e not in ['.exe', '.com', '.bat']:
>  command[0] = command[0] + '.exe'
> -proc = subprocess.Popen(command, shell = shell,
> -cwd = cwd, env = env,
> -stdin = stdin, stdout = stdout,
> -stderr = stderr,
> -close_fds = False)
> +
> +pipe_commands = []
> +current_command = []
> +for cmd in command:
> +if cmd == '|':
> +pipe_commands.append(current_command)
> +current_command = []
> +else:
> +current_command.append(cmd)
> +pipe_commands.append(current_command)
> +
> +proc = None
> +for i, cmd in enumerate(pipe_commands):
> +if i == 0:
> +proc = subprocess.Popen(
> +cmd, shell=shell,
> +cwd=cwd, env=env,
> +stdin=stdin, stdout=subprocess.PIPE)
> +elif i == len(pipe_commands) - 1:
> +proc = subprocess.Popen(
> +cmd, shell=shell,
> +cwd=cwd, env=env,
> +stdin=proc.stdout,
> +stdout=stdout, stderr=stderr,
> +close_fds=False)
> +else:
> +proc = subprocess.Popen(
> +cmd, shell=shell,
> +cwd=cwd, env=env,
> +stdin=proc.stdout,
> +stdout=subprocess.PIPE)
> +
>  if not capture:
>  return (0, proc)
>  if self.output is None:
> @@ -583,6 +610,10 @@ if __name__ == "__main__":
>  proc.stdin.close()
>  e.capture(proc)
>  del proc
> +ec, proc = e.open(commands['open'])
> +if ec == 0:
> +e.capture(proc)
> +del proc
>  
>  def capture_output(text):
>  print(text, end = '')
> @@ -601,6 +632,7 @@ if __name__ == "__main__":
>  commands['windows']['csubsts'] = [('netstat %0', ['-a']),
>('netstat %0 %1', ['-a', '-n'])]
>  commands['windows']['pipe'] = ('ftp', None, 'help\nquit')
> +commands['windows']['open'] = ["echo",  "hello rtems", "|", "findstr", 
> "rtems"]
>  commands['unix']['shell'] = ['pwd', 'ls -las', './xyz', sh_shell_test]
>  commands['unix']['spawn'] = ['ls', 'execute.pyc', ['ls', '-i']]
>  commands['unix']['cmd'] = [('date'), ('date', '-R'), ('date', ['-u', 
> '+%d %D']),
> @@ -608,6 +640,7 @@ if __name__ == "__main__":
>  commands['unix']['csubsts'] = [('date %0 "+%d %D %S"', ['-u']),
> ('date %0 %1', ['-u', '+%d %D %S'])]
>  commands['unix']['pipe'] = ('grep', 'hello', 'hello world')
> +commands['unix']['open'] = ["echo", "hello world", "|", "cut", "-d ", 
> "-f2"]
>  
>  print(arg_list('cmd a1 a2 "a3 is a string" a4'))
>  print(arg_list('cmd b1 b2 "b3 is a string a4'))
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] rtemstoolkit: add support for executing pipe command

[Chris Johns]

Hi,

Thanks for this. I like the change.

Could you please shorten the long line? This code will be run through yapf after
6 branches but until then we limit the line length. :)

Could you please add a unit test for this to the end of this file?

Thanks
Chris

On 20/6/2023 8:44 am, Muhammad Sulthan Mazaya wrote:
> The previous implementation of execute command on rtems-tools config does
> not support command line pipe operation. So something like:
> 
> %execute %{command} | %{trim_command}
> 
> Would not work, since the "| %{trim_command}" part is treated as an 
> additional command option. This patch is intended to fix that issue.
> 
> ---
>  rtemstoolkit/execute.py | 28 +++-
>  1 file changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/rtemstoolkit/execute.py b/rtemstoolkit/execute.py
> index ed81589..9bb7434 100755
> --- a/rtemstoolkit/execute.py
> +++ b/rtemstoolkit/execute.py
> @@ -389,11 +389,29 @@ class execute(object):
>  r, e = os.path.splitext(command[0])
>  if e not in ['.exe', '.com', '.bat']:
>  command[0] = command[0] + '.exe'
> -proc = subprocess.Popen(command, shell = shell,
> -cwd = cwd, env = env,
> -stdin = stdin, stdout = stdout,
> -stderr = stderr,
> -close_fds = False)
> +
> +pipe_commands = []
> +current_command = []
> +for cmd in command:
> +if cmd == '|':
> +pipe_commands.append(current_command)
> +current_command = []
> +else:
> +current_command.append(cmd)
> +pipe_commands.append(current_command)
> +
> +proc = None
> +for i, cmd in enumerate(pipe_commands):
> +if i == 0:
> +proc = subprocess.Popen(
> +cmd, shell=shell, cwd=cwd, env=env, stdin=stdin, 
> stdout=subprocess.PIPE)
> +elif i == len(pipe_commands) - 1:
> +proc = subprocess.Popen(
> +cmd, shell=shell, cwd=cwd, env=env, 
> stdin=proc.stdout, stdout=stdout, stderr=stderr, close_fds=False)
> +else:
> +proc = subprocess.Popen(
> +cmd, shell=shell, cwd=cwd, env=env, 
> stdin=proc.stdout, stdout=subprocess.PIPE)
> +
>  if not capture:
>  return (0, proc)
>  if self.output is None:
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: doctest rtems example

[Chris Johns]

Hi Sam,

Thanks for the post. The website for the code is:

https://github.com/doctest/doctest

I have been using this and I can port tests between Linux and RTEMS. I like it
because it works and it is a single header. There is no need to build and link
libraries.

Chris

On 16/6/2023 11:07 pm, Sam Price wrote:
> /* Tell doctest to not use its own main */
> #define DOCTEST_CONFIG_IMPLEMENT
> /* tell doctest to not use sigint that rtems does not have */
> #define DOCTEST_CONFIG_NO_POSIX_SIGNALS
> #include "doctest.h"
> 
> /* Setup command line part */
> const char rtems_test_name[] = "DOCTEST UNIT TESTS";
> 
> static int run_doctest_tests(int argc, char **argv) {
> 
> // Initialize doctest context
> doctest::Context context(argc, argv);
> 
> int test_result = context.run(); // run queries, or run tests unless --no-run
> 
> if(context.shouldExit()) // honor query flags and --exit
> return test_result;
> return 0;
> }
> 
> rtems_shell_cmd_t Shell_DOCTEST_Command = {
> "doctest", /* name */
> "doctest [doctest options]", /* usage */
> "tests", /* topic */
> run_doctest_tests, /* command */
> NULL, /* alias */
> NULL /* next */
> };
> 
> /* Inside of your Init add the following prior to starting shell */
> rtems_task Init(rtems_task_argument ignored)
> {
> 
> 
> rtems_shell_add_cmd_struct(_DOCTEST_Command);
> /* Note i made this high priority, some of my tests require priority access. 
> */
> /* It may be better to use 100, and use the following in your test
> rtems_task_priority old_priority;
> rtems_task_set_priority(RTEMS_SELF, 0, _priority);
> ...
> rtems_task_set_priority(RTEMS_SELF, old_priority, 0x0);
> */
> 
> rtems_shell_init("shell0", 20 * 1024, 2, "/dev/console", 0, 1, NULL);
> ...
> }
> 
> TEST_CASE("testing the addition function") {
> CHECK((2 + 2) == 4);
> CHECK((2 + 2) == 4.0);
> }
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP .inc files and .cfg files

[Chris Johns]

On 17/6/2023 5:30 am, Joel Sherrill wrote:
> On Fri, Jun 16, 2023 at 3:18 AM Philip Kirkpatrick
> mailto:p.kirkpatr...@reflexaerospace.com>>
> wrote:
> 
> For the RPU patch, I'll add removing this to my next pass at it.
> 
> If there is some transformation on the linked executable needed to download 
> it,
> I hope you document that entire process in the Users Guide. :)

I suspect there is a whole book on how that could be done.

On the Versal it may be as simple as an SMC call but I would need to check the
calls on the Versal [1]. I think it would take a binary image in DDR. I am not
sure what is needed on the ZymqMP?

Chris

[1] https://github.com/kiwichris/rtems-xilinx-xrt/tree/main/rtems
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bsps/xilinx-zynqmp : Add BSP for RPU

[Chris Johns]

On 17/6/2023 5:14 am, Gedare Bloom wrote:
> On Fri, Jun 16, 2023 at 2:17 AM Philip Kirkpatrick
>  wrote:
>> On Fri, Jun 16, 2023 at 7:14 AM Chris Johns  wrote:
>>>
>>> On 15/6/2023 6:16 pm, Philip Kirkpatrick wrote:
>>>> Thanks for all the good feedback.
>>>>
>>>> RE Joel:
>>>> I'll fix my sloppy formatting that you caught and submit a revised patch.  
>>>> If
>>>> I'm realistic about my schedule, I probably won't be able to get to it 
>>>> until
>>>> next week.
>>>> For xttcps_hw.h, there already is one #ifndef __rtems__ around the 
>>>> #includes,
>>>> but on review there is another spot where I got lazy and used a #if 0.  
>>>> I'll
>>>> correct that too.  Other than that, the file is unmodified.
>>>>
>>>> On the discussion about a shared space, I'll leave that decision up to you.
>>>> Tell me what you want and I can adjust as needed, or it could be done in a
>>>> follow-on patch.
>>>
>>> Should the RPU BSP be located under bsps/arm/xilinx-rpu?
>>
>>
>> I went back and forth on that decision and decided to keep them combined 
>> since the APU and RPU share a moderate amount of code.  However, I can 
>> definitely see an argument that they are different enough to split.  If you 
>> want it the other way, I can make that change when I address the other items.

Thanks, I think this is worth while.

> I think we should split it out. Shared code should likely be
> refactored to arm/shared depending what that is.

Agreed. I am fine with the code moving, leaving the arm/xilinx-zynqmp BSP as is
because it may be removed (see below).

> I'm not sure that carrying forward a 32-bit arm/xilinx-zynqmp makes
> sense now that we have a functional aarch64 port. Splitting the RPU
> out will make it easier to make that decision.

I agree. I think it is confusing. I also think it should happen before 6.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

New website to accompany ctakes 5 release; suggestions requested

[Johns, Dennis]

Hello all,

I'm working on a new website for the release of ctakes 5 and was hoping to get 
some feedback from you about color scheme, necessary links, any other ideas you 
might have.

To follow the Apache branding 
policy while also being able to 
use github pages to host a new website https://apache.github.io/ctakes-website/ 
users will go to http://ctakes.apache.org/ and then get redirected to the new 
website after a couple of seconds. The downloads page will be completed when 
the release is ready.  Until then it is a placeholder.

I'd also like to mention that ctakes committers already have rights as long as 
they have linked their apache account to a github account.  One way to do this 
is by using the boxer service https://gitbox.apache.org/boxer/ . Any linked 
committers can also edit the wiki.

Please respond to this email with any questions or suggestions.  I am still new 
to ctakes so any assistance is appreciated!

P.s. (If anybody has Jekyll knowledge then your assistance would be greatly 
appreciated.)

Thank you for your time and have a great weekend,
Dennis

Re: [PATCH 2/2] bsps: Remove uses of BSP-specific interrupt API

[Chris Johns]

On 16/6/2023 3:36 pm, Sebastian Huber wrote:
> On 16.06.23 07:04, Chris Johns wrote:
>> On 16/6/2023 2:51 pm, Sebastian Huber wrote:
>>> On 16.06.23 03:49, Chris Johns wrote:
>>>>> diff --git a/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>>>> b/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>>>> index 96b77907a6..bc211e37b6 100644
>>>>> --- a/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>>>> +++ b/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>>>> @@ -41,7 +41,7 @@
>>>>>    #include 
>>>>>      #include 
>>>>> -#include 
>>>>> +#include 
>>>>>      #include 
>>>>>    @@ -227,7 +227,7 @@ static int ambapp_grlib_int_clear
>>>>>    struct drvmgr_dev *dev,
>>>>>    int irq)
>>>>>    {
>>>>> -    BSP_shared_interrupt_clear(irq);
>>>>> +    (void) rtems_interrupt_clear(irq);
>>>>>    return DRVMGR_OK;
>>>> Why ignore the return code of the clear and assume the result is OK?
>>>>
>>>> This pattern is repeated in other places.
>>>
>>> This is how it is. I didn't want to introduce functional or API changes with
>>> this patch set.
>>
>> I do not see the API change.
>>
>> If the code here is looking through the interface provided to the 
>> implementation
>> so it knows no error will be returned then it is functionally equivalent to 
>> what
>> exists if the error is checked. Nothing changes. The problem with the change 
>> is
>> using the interface implies the error is being checked and a change in the
>> implementation to return an error would not be handled here. Leaving a latent
>> issue like that does not seem right?
> 
> The BSP_shared_interrupt*() functions have no return value and they didn't 
> check
> anything. The patch was supposed to be a simple change from one API to 
> another.
> I added some error checks to v2 of the patch set.

I appreciate this. The interfaces that return void have no where to go and that
is fine. The ones discussed and updated are different. I was not explicit about
this. The v2 means it is one less thing to deal with later.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 1/3] pci: Do not use BSP-specific interrupt API

[Chris Johns]

Look good.

Thanks
Chris

On 16/6/2023 3:34 pm, Sebastian Huber wrote:
> Update #3269.
> ---
>  cpukit/include/pci/irq.h | 17 -
>  1 file changed, 4 insertions(+), 13 deletions(-)
> 
> diff --git a/cpukit/include/pci/irq.h b/cpukit/include/pci/irq.h
> index 4069f1ffa8..8617dd1680 100644
> --- a/cpukit/include/pci/irq.h
> +++ b/cpukit/include/pci/irq.h
> @@ -38,18 +38,9 @@
>  #ifndef __PCI_IRQ_H__
>  #define __PCI_IRQ_H__
>  
> -#include 
> +#include 
>  #include 
>  
> -/*
> - * FIXME: This should be available via the IRQ extensions API.
> - *
> - * https://devel.rtems.org/ticket/3269
> - */
> -void BSP_shared_interrupt_clear(int irq);
> -void BSP_shared_interrupt_unmask(int irq);
> -void BSP_shared_interrupt_mask(int irq);
> -
>  /* PCI Handler (ISR) called when IRQ is generated by any of the PCI devices
>   * connected to the same PCI IRQ Pin. This has been defined the same way as
>   * rtems_interrupt_handler in order for BSPs to "direct-map" the register
> @@ -106,7 +97,7 @@ static inline int pci_interrupt_unregister(int irq, 
> pci_isr isr,
>   */
>  static inline void pci_interrupt_unmask(int irq)
>  {
> - BSP_shared_interrupt_unmask(irq);
> + (void)rtems_interrupt_vector_enable((rtems_vector_number)irq);
>  }
>  
>  /* Disable shared PCI IRQ handler. This function will mask the interrupt
> @@ -122,7 +113,7 @@ static inline void pci_interrupt_unmask(int irq)
>   */
>  static inline void pci_interrupt_mask(int irq)
>  {
> - BSP_shared_interrupt_mask(irq);
> + (void)rtems_interrupt_vector_disable((rtems_vector_number)irq);
>  }
>  
>  /* Acknowledge the interrupt controller by writing to the interrupt 
> controller.
> @@ -136,7 +127,7 @@ static inline void pci_interrupt_mask(int irq)
>   */
>  static inline void pci_interrupt_clear(int irq)
>  {
> - BSP_shared_interrupt_clear(irq);
> + (void)rtems_interrupt_clear((rtems_vector_number)irq);
>  }
>  
>  #endif /* !__PCI_IRQ_H__ */
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bsps/xilinx-zynqmp : Add BSP for RPU

[Chris Johns]

On 15/6/2023 6:16 pm, Philip Kirkpatrick wrote:
> Thanks for all the good feedback.
> 
> RE Joel:
> I'll fix my sloppy formatting that you caught and submit a revised patch.  If
> I'm realistic about my schedule, I probably won't be able to get to it until
> next week.
> For xttcps_hw.h, there already is one #ifndef __rtems__ around the #includes,
> but on review there is another spot where I got lazy and used a #if 0.  I'll
> correct that too.  Other than that, the file is unmodified.
> 
> On the discussion about a shared space, I'll leave that decision up to you. 
> Tell me what you want and I can adjust as needed, or it could be done in a
> follow-on patch.

Should the RPU BSP be located under bsps/arm/xilinx-rpu?

> For the Versal, I've never used that part and am not very familiar with it, 
> but
> the feedback from Aaron makes it sound like the core is probably pretty
> similar.  One other possible difference would be in the timers but it does 
> look
> like the Versal has the same TTCs.  There just may be a small bit of work to 
> set
> up the clock input to it.

We would handle the Versal once the BSP has a home.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] bsps: Remove uses of BSP-specific interrupt API

[Chris Johns]

On 16/6/2023 2:51 pm, Sebastian Huber wrote:
> On 16.06.23 03:49, Chris Johns wrote:
>>> diff --git a/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>> b/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>> index 96b77907a6..bc211e37b6 100644
>>> --- a/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>> +++ b/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>> @@ -41,7 +41,7 @@
>>>   #include 
>>>     #include 
>>> -#include 
>>> +#include 
>>>     #include 
>>>   @@ -227,7 +227,7 @@ static int ambapp_grlib_int_clear
>>>   struct drvmgr_dev *dev,
>>>   int irq)
>>>   {
>>> -    BSP_shared_interrupt_clear(irq);
>>> +    (void) rtems_interrupt_clear(irq);
>>>   return DRVMGR_OK;
>> Why ignore the return code of the clear and assume the result is OK?
>>
>> This pattern is repeated in other places.
> 
> This is how it is. I didn't want to introduce functional or API changes with
> this patch set.

I do not see the API change.

If the code here is looking through the interface provided to the implementation
so it knows no error will be returned then it is functionally equivalent to what
exists if the error is checked. Nothing changes. The problem with the change is
using the interface implies the error is being checked and a change in the
implementation to return an error would not be handled here. Leaving a latent
issue like that does not seem right?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP-Specific Testing was: [PATCH 00/34] Integrate pre-qualified LEON3 BSP

[Chris Johns]

On 16/6/2023 2:41 pm, Sebastian Huber wrote:
> On 16.06.23 00:07, Chris Johns wrote:
>> On 16/6/2023 12:54 am, Sebastian Huber wrote:
>>> The test framework prints out the location of events using the file name 
>>> and the
>>> line number. So, it would be good if the file names are unique and 
>>> descriptive.
>>> This is why I like Gedare's proposal to just use "bsps".
>> Is only the basename embedded in the file name, the full path or some form 
>> of a
>> relative path?
> 
> Just the basename is printed

Should the fact the file name should be unique to avoid confusion as it is just
the basename be documented in the eng manual? I could not see it mentioned.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Doorstop YML file in repo

[Chris Johns]

On 16/6/2023 2:34 pm, Sebastian Huber wrote:
> On 16.06.23 00:33, Chris Johns wrote:
>> Hi
>>
>> I spotted this today and I am wondering if it has accidental been added:
>>
>> https://git.rtems.org/rtems/tree/spec/build/bsps/arm/stm32h7/.doorstop.yml
>>
>> ?
> 
> Sorry, this was a mistake. I removed the file.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP .inc files and .cfg files

[Chris Johns]

On 16/6/2023 2:33 pm, Sebastian Huber wrote:
> On 16.06.23 03:46, Chris Johns wrote:
>>
>> On 16/6/2023 9:04 am, Joel Sherrill wrote:
>>>
>>> On Thu, Jun 15, 2023 at 5:41 PM Chris Johns >> <mailto:chr...@rtems.org>> wrote:
>>>
>>>  Hi,
>>>
>>>  Reviewing the RPU patch I noticed a .inc file being added and I 
>>> wondered
>>> why so
>>>  I checked the sources and to my surprise found:
>>>
>>>  rtems.git $ find bsps -name \*.inc
>>>  bsps/v850/gdbv850sim/config/v850sim.inc
>>>  bsps/m68k/genmcf548x/config/genmcf548x.inc
>>>  bsps/m68k/gen68340/include/m68340.inc
>>>  bsps/m68k/gen68340/include/m68349.inc
>>>  bsps/arm/altera-cyclone-v/config/altcycv.inc
>>>  bsps/arm/raspberrypi/config/raspberrypi.inc
>>>  bsps/arm/lpc32xx/config/lpc32xx.inc
>>>  bsps/arm/beagle/config/beagle.inc
>>>  bsps/arm/tms570/config/tms570ls3137.inc
>>>  bsps/arm/xilinx-zynqmp/config/xilinx_zynqmp.inc
>>>  bsps/arm/xilinx-zynq/config/xilinx_zynq.inc
>>>  bsps/arm/lpc24xx/config/lpc17xx.inc
>>>  bsps/arm/lpc24xx/config/lpc40xx.inc
>>>  bsps/arm/lpc24xx/config/lpc24xx.inc
>>>  bsps/arm/lm3s69xx/config/lm3s69xx.inc
>>>  bsps/powerpc/gen5200/config/gen5200.inc
>>>  bsps/powerpc/tqm8xx/config/tqm8xx.inc
>>>  bsps/powerpc/mpc55xxevb/config/mpc55xx.inc
>>>  bsps/powerpc/qoriq/config/qoriq.inc
>>>  bsps/powerpc/gen83xx/config/gen83xx.inc
>>>
>>>
>>> These likely can. Thinking back, we have cfg files for every BSP
>>> variant within a family. They often set a variable like CPU and CPU_CFLAGS
>>> and included a shared .inc file. These all appear to be from BSPs which
>>> had variants. I think they are remnants and missed when the .cfg files
>>> were
>>>
>>> Would like someone to concur.
>>>
>>>
>>>  And for .cfg there is:
>>>
>>>  rtems.git $ find bsps -name \*.cfg | wc -l
>>>       191
>>>
>>>
>>> Are these installed and used by the application Makefile system. If so, no.
>> I cannot see any references in spec but Sebastian is the best person to 
>> answer
>> this.
> 
> They are definitely not used or installed. I think we still have then since 
> they
> document the post-link actions which are not yet supported by the new build 
> system.

Ah yes, thanks. What if the files are collected and archived?

The RPU BSP is adding a new one. Is this what we want to see happen?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] bsps: Remove uses of BSP-specific interrupt API

[Chris Johns]

On 15/6/2023 10:46 pm, Sebastian Huber wrote:
> Update #3269.
> ---
>  bsps/riscv/griscv/include/bsp.h |  4 ---
>  bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c |  8 +++---
>  bsps/sparc/erc32/include/bsp.h  | 15 ---
>  bsps/sparc/leon2/include/bsp.h  | 15 ---
>  bsps/sparc/leon3/include/bsp.h  | 15 ---
>  bsps/sparc/shared/drvmgr/leon2_amba_bus.c   |  5 ++--
>  bsps/sparc/shared/irq/irq-shared.c  | 29 -
>  spec/build/bsps/sparc/leon3/obj.yml |  1 -
>  8 files changed, 43 insertions(+), 49 deletions(-)
> 
> diff --git a/bsps/riscv/griscv/include/bsp.h b/bsps/riscv/griscv/include/bsp.h
> index 9d6fb2a16f..c7d24839ca 100644
> --- a/bsps/riscv/griscv/include/bsp.h
> +++ b/bsps/riscv/griscv/include/bsp.h
> @@ -71,10 +71,6 @@ extern "C" {
>  
>  /* GRLIB driver functions */
>  
> -extern void BSP_shared_interrupt_mask(int irq);
> -extern void BSP_shared_interrupt_clear(int irq);
> -extern void BSP_shared_interrupt_unmask(int irq);
> -
>  /*
>   * Network driver configuration for greth
>   */
> diff --git a/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c 
> b/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
> index 96b77907a6..bc211e37b6 100644
> --- a/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
> +++ b/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
> @@ -41,7 +41,7 @@
>  #include 
>  
>  #include 
> -#include 
> +#include 
>  
>  #include 
>  
> @@ -227,7 +227,7 @@ static int ambapp_grlib_int_clear
>   struct drvmgr_dev *dev,
>   int irq)
>  {
> - BSP_shared_interrupt_clear(irq);
> + (void) rtems_interrupt_clear(irq);
>   return DRVMGR_OK;

Why ignore the return code of the clear and assume the result is OK?

This pattern is repeated in other places.

Chris
>  }
>  
> @@ -237,7 +237,7 @@ static int ambapp_grlib_int_mask
>   int irq
>   )
>  {
> - BSP_shared_interrupt_mask(irq);
> + bsp_interrupt_vector_disable(irq);
>   return DRVMGR_OK;
>  }
>  
> @@ -247,7 +247,7 @@ static int ambapp_grlib_int_unmask
>   int irq
>   )
>  {
> - BSP_shared_interrupt_unmask(irq);
> + bsp_interrupt_vector_enable(irq);
>   return DRVMGR_OK;
>  }
>  
> diff --git a/bsps/sparc/erc32/include/bsp.h b/bsps/sparc/erc32/include/bsp.h
> index fd453fb6c2..cb62661aa1 100644
> --- a/bsps/sparc/erc32/include/bsp.h
> +++ b/bsps/sparc/erc32/include/bsp.h
> @@ -142,7 +142,10 @@ static __inline__ int BSP_shared_interrupt_unregister
>   * Arguments
>   *  irq   System IRQ number
>   */
> -extern void BSP_shared_interrupt_clear(int irq);
> +static inline void BSP_shared_interrupt_clear( int irq )
> +{
> +  (void) rtems_interrupt_clear( (rtems_vector_number) irq );
> +}
>  
>  /* Enable Interrupt. This function will unmask the IRQ at the interrupt
>   * controller. This is normally done by _register(). Note that this will
> @@ -151,7 +154,10 @@ extern void BSP_shared_interrupt_clear(int irq);
>   * Arguments
>   *  irq   System IRQ number
>   */
> -extern void BSP_shared_interrupt_unmask(int irq);
> +static inline void BSP_shared_interrupt_unmask( int irq )
> +{
> +  (void) rtems_interrupt_vector_enable( (rtems_vector_number) irq );
> +}
>  
>  /* Disable Interrupt. This function will mask one IRQ at the interrupt
>   * controller. This is normally done by _unregister().  Note that this will
> @@ -160,7 +166,10 @@ extern void BSP_shared_interrupt_unmask(int irq);
>   * Arguments
>   *  irq System IRQ number
>   */
> -extern void BSP_shared_interrupt_mask(int irq);
> +static inline void BSP_shared_interrupt_mask( int irq )
> +{
> +  (void) rtems_interrupt_vector_disable( (rtems_vector_number) irq );
> +}
>  
>  /*
>   *  Delay for the specified number of microseconds.
> diff --git a/bsps/sparc/leon2/include/bsp.h b/bsps/sparc/leon2/include/bsp.h
> index 510262206b..4a2f5967ef 100644
> --- a/bsps/sparc/leon2/include/bsp.h
> +++ b/bsps/sparc/leon2/include/bsp.h
> @@ -166,7 +166,10 @@ static __inline__ int BSP_shared_interrupt_unregister
>   * Arguments
>   *  irq   System IRQ number
>   */
> -extern void BSP_shared_interrupt_clear(int irq);
> +static inline void BSP_shared_interrupt_clear( int irq )
> +{
> +  (void) rtems_interrupt_clear( (rtems_vector_number) irq );
> +}
>  
>  /* Enable Interrupt. This function will unmask the IRQ at the interrupt
>   * controller. This is normally done by _register(). Note that this will
> @@ -175,7 +178,10 @@ extern void BSP_shared_interrupt_clear(int irq);
>   * Arguments
>   *  irq   System IRQ number
>   */
> -extern void BSP_shared_interrupt_unmask(int irq);
> +static inline void BSP_shared_interrupt_unmask( int irq )
> +{
> +  (void) rtems_interrupt_vector_enable( (rtems_vector_number) irq );
> +}
>  
>  /* Disable Interrupt. This function will mask one IRQ at the interrupt
>   * controller. This is normally done by _unregister().  Note that this will
> @@ -184,7 +190,10 @@ extern void BSP_shared_interrupt_unmask(int irq);
>   * 

Re: BSP .inc files and .cfg files

[Chris Johns]

On 16/6/2023 9:04 am, Joel Sherrill wrote:
> 
> 
> On Thu, Jun 15, 2023 at 5:41 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> Hi,
> 
> Reviewing the RPU patch I noticed a .inc file being added and I wondered 
> why so
> I checked the sources and to my surprise found:
> 
> rtems.git $ find bsps -name \*.inc
> bsps/v850/gdbv850sim/config/v850sim.inc
> bsps/m68k/genmcf548x/config/genmcf548x.inc
> bsps/m68k/gen68340/include/m68340.inc
> bsps/m68k/gen68340/include/m68349.inc
> bsps/arm/altera-cyclone-v/config/altcycv.inc
> bsps/arm/raspberrypi/config/raspberrypi.inc
> bsps/arm/lpc32xx/config/lpc32xx.inc
> bsps/arm/beagle/config/beagle.inc
> bsps/arm/tms570/config/tms570ls3137.inc
> bsps/arm/xilinx-zynqmp/config/xilinx_zynqmp.inc
> bsps/arm/xilinx-zynq/config/xilinx_zynq.inc
> bsps/arm/lpc24xx/config/lpc17xx.inc
> bsps/arm/lpc24xx/config/lpc40xx.inc
> bsps/arm/lpc24xx/config/lpc24xx.inc
> bsps/arm/lm3s69xx/config/lm3s69xx.inc
> bsps/powerpc/gen5200/config/gen5200.inc
> bsps/powerpc/tqm8xx/config/tqm8xx.inc
> bsps/powerpc/mpc55xxevb/config/mpc55xx.inc
> bsps/powerpc/qoriq/config/qoriq.inc
> bsps/powerpc/gen83xx/config/gen83xx.inc
> 
> 
> These likely can. Thinking back, we have cfg files for every BSP
> variant within a family. They often set a variable like CPU and CPU_CFLAGS
> and included a shared .inc file. These all appear to be from BSPs which
> had variants. I think they are remnants and missed when the .cfg files
> were 
> 
> Would like someone to concur. 
> 
> 
> And for .cfg there is:
> 
> rtems.git $ find bsps -name \*.cfg | wc -l
>      191
> 
> 
> Are these installed and used by the application Makefile system. If so, no. 

I cannot see any references in spec but Sebastian is the best person to answer 
this.

Chris

> But if these were just the ".cfg" files I mentioned above, then likely yes. We
> probably had 191 BSPs which we switched to waf.
> 
> 
> Can these files be removed?
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org <mailto:devel@rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

BSP .inc files and .cfg files

[Chris Johns]

Hi,

Reviewing the RPU patch I noticed a .inc file being added and I wondered why so
I checked the sources and to my surprise found:

rtems.git $ find bsps -name \*.inc
bsps/v850/gdbv850sim/config/v850sim.inc
bsps/m68k/genmcf548x/config/genmcf548x.inc
bsps/m68k/gen68340/include/m68340.inc
bsps/m68k/gen68340/include/m68349.inc
bsps/arm/altera-cyclone-v/config/altcycv.inc
bsps/arm/raspberrypi/config/raspberrypi.inc
bsps/arm/lpc32xx/config/lpc32xx.inc
bsps/arm/beagle/config/beagle.inc
bsps/arm/tms570/config/tms570ls3137.inc
bsps/arm/xilinx-zynqmp/config/xilinx_zynqmp.inc
bsps/arm/xilinx-zynq/config/xilinx_zynq.inc
bsps/arm/lpc24xx/config/lpc17xx.inc
bsps/arm/lpc24xx/config/lpc40xx.inc
bsps/arm/lpc24xx/config/lpc24xx.inc
bsps/arm/lm3s69xx/config/lm3s69xx.inc
bsps/powerpc/gen5200/config/gen5200.inc
bsps/powerpc/tqm8xx/config/tqm8xx.inc
bsps/powerpc/mpc55xxevb/config/mpc55xx.inc
bsps/powerpc/qoriq/config/qoriq.inc
bsps/powerpc/gen83xx/config/gen83xx.inc

And for .cfg there is:

rtems.git $ find bsps -name \*.cfg | wc -l
 191

Can these files be removed?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Doorstop YML file in repo

[Chris Johns]

Hi

I spotted this today and I am wondering if it has accidental been added:

https://git.rtems.org/rtems/tree/spec/build/bsps/arm/stm32h7/.doorstop.yml

?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP-Specific Testing was: [PATCH 00/34] Integrate pre-qualified LEON3 BSP

[Chris Johns]

On 16/6/2023 12:54 am, Sebastian Huber wrote:
> The test framework prints out the location of events using the file name and 
> the
> line number. So, it would be good if the file names are unique and 
> descriptive.
> This is why I like Gedare's proposal to just use "bsps".

Is only the basename embedded in the file name, the full path or some form of a
relative path?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] qemu-5-1: Add patch for ZynqMP/Versal CGEMs

[Chris Johns]

OK

Thanks
Chris

On 16/6/2023 1:53 am, Kinsey Moore wrote:
> This temporarily adds a patch to fix badly behaving CGEM peripherals
> under QEMU. The referenced patch has been submitted for inclusion in
> the upstream QEMU repository.
> 
> Updates #4919
> ---
>  source-builder/config/qemu-5-1.cfg | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/source-builder/config/qemu-5-1.cfg 
> b/source-builder/config/qemu-5-1.cfg
> index 7ca58b8..4b2951d 100644
> --- a/source-builder/config/qemu-5-1.cfg
> +++ b/source-builder/config/qemu-5-1.cfg
> @@ -7,3 +7,7 @@
>  %define qemu_disables --disable-nettle
>  
>  %include %{_configdir}/qemu-common-2.cfg
> +
> +%patch add qemu --rsb-file=cgem_zynqmp_versal.patch -p1 
> https://devel.rtems.org/raw-attachment/ticket/4919/cgem_zynqmp_versal.patch
> +%hash sha512 cgem_zynqmp_versal.patch \
> +  
> 2a4a894acefd00a76f48b6d6339696c8c53ece8e044687cb86c268840eac226d251fe89af933db4c20f5f07a3faff92c7c28c4c82b0617e4b200fd0895ac6158
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel