Re: [PATCH] build: Add target to build scripts

[Chris Johns]

On 10/8/2023 7:02 pm, Sebastian Huber wrote:
> Document that the build scripts in the testsuites produce a test program.

I am sorry but I do not understand this change and why we need it. Is the
addition of the target line purely cosmetic?

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

Re: [PATCH] build: Make BUILD_LIBDL configurable

[Chris Johns]

On 10/8/2023 11:44 pm, Sebastian Huber wrote:
> On 10.08.23 15:28, Joel Sherrill wrote:
>> It looks ok but why? It isn't built if not supported. It isn't a lot of code
>> even if it is built. And it will not be in a user executable if they don't
>> call it.
>>
>> I just don't see the point.
> 
> Yes, good question. Actually, I wanted to add an option to disable the libdl
> tests as a workaround for
> 
> http://devel.rtems.org/ticket/4941
> 
> and the use of vendor tools or clang. I will make this more explicit with a
> BUILD_LIBDL_TESTS option.

Please do not add a work around.

Thanks
Chris

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

Re: [PATCH rtems v3 1/1] Add the Regulator Interface and test

[Chris Johns]

On 11/8/2023 8:14 am, Joel Sherrill wrote:
> I should have asked if you want another round of patches or just go ahead and
> merge. This set of changes was pretty minor.

I am fine with the changes being pushed.

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

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 10/8/2023 3:06 pm, Sebastian Huber wrote:
> On 10.08.23 03:13, Chris Johns wrote:
>>
>> On 9/8/2023 7:12 pm, Sebastian Huber wrote:
>>> On 09.08.23 11:10, Cedric Berger wrote:
>>>> On 09.08.23 10:51, Sebastian Huber wrote:
>>>>> We could add some text to the option description:
>>>>>
>>>>> # Defines the program prefix of tools (compiler, assembler, linker).
>>>>> # This option may be used to build RTEMS with a vendor tool suite.
>>>>> # Please note that using tool suites not provided by the RTEMS Project
>>>>> # may not work as expected.
>>>> If the goal of that comment it to prevent "fielding support related
>>>> questions", I doubt that writing "may not work as expected" will have the
>>>> desired effect...
>>> I am open for alternative wordings.
>>>
>> # Defines the program prefix of tools (compiler, assembler, linker) used
>> # to build RTEMS. This option may be used to build RTEMS with a vendor
>> # tool suite. Please note, support issues related to using this option with
>> # vendor tool suites should be directed to the vendor of the tools.
> 
> Sounds good, do you check it in?

I have not. Are you able to? If so please feel free to push the change as 
approved.

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

Re: [PATCH rtems v3 1/1] Add the Regulator Interface and test

[Chris Johns]

Hi Joel,

This looks good.

A minor nit relates to pointer checks. We have:

https://docs.rtems.org/branches/master/eng/coding-conventions.html#language-and-compiler

I do not know how well enforced the pointer check for NULL in `if` is?

Chris

On 10/8/2023 1:42 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  |  499 +++
>  cpukit/include/rtems/regulatorimpl.h  |  135 ++
>  cpukit/libmisc/regulator/regulator.c  |  683 +
>  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 | 1310 +
>  .../libtests/regulator01/regulator01.doc  |   67 +
>  .../libtests/regulator01/rtems_config.c   |   59 +
>  10 files changed, 2796 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..362a99f6bc
> --- /dev/null
> +++ b/cpukit/include/rtems/regulator.h
> @@ -0,0 +1,499 @@
> +/* 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 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 destination.
> + *
> + * 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 from the producer/source side:
> + *
> + * @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)
> + * @endcode
> + *
> + * The delivery of message buffers to the Destination and subsequent
> + * release is performed in the context of the delivery thread by either
> + * the delivery function or delivery thread. Details are below.
> + *
> + * 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 

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 9/8/2023 7:12 pm, Sebastian Huber wrote:
> On 09.08.23 11:10, Cedric Berger wrote:
>> On 09.08.23 10:51, Sebastian Huber wrote:
>>> We could add some text to the option description:
>>>
>>> # Defines the program prefix of tools (compiler, assembler, linker).
>>> # This option may be used to build RTEMS with a vendor tool suite.
>>> # Please note that using tool suites not provided by the RTEMS Project
>>> # may not work as expected.
>>
>> If the goal of that comment it to prevent "fielding support related
>> questions", I doubt that writing "may not work as expected" will have the
>> desired effect...
> 
> I am open for alternative wordings.
> 

# Defines the program prefix of tools (compiler, assembler, linker) used
# to build RTEMS. This option may be used to build RTEMS with a vendor
# tool suite. Please note, support issues related to using this option with
# vendor tool suites should be directed to the vendor of the tools.

?

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

Re: [PATCH RTEMS] spec: Add -mstrict-align to mvme2100 default build

[Chris Johns]

On 10/8/2023 2:41 am, Joel Sherrill wrote:
> Reading the EPICS discussion, I wonder if this should be added for all
> motorola_powerpc BSP variants.
> 
> Gedare/Chris/anyone with another board in the family? What do you think?

Michael asked if the setting is present when building libc, libm etc in the
EPICS core devs meeting today and I could not answer the question? Is it
exported in the .pc or Makefile.inc flags?

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

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 8/8/2023 11:14 pm, Sebastian Huber wrote:
> On 08.08.23 08:06, Chris Johns wrote:
>> n 7/8/2023 4:06 pm, Sebastian Huber wrote:
>>> On 07.08.23 00:25, Chris Johns wrote:
>>>> On 4/8/2023 4:39 pm, Sebastian Huber wrote:
>>>>> On 04.08.23 08:22, Chris Johns wrote:
>>>>>> On 4/8/2023 3:16 pm, Sebastian Huber wrote:
>>>>>>> On 04.08.23 00:27, Chris Johns wrote:
>>>>>>>> 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.
>>>>>>> Sorry I thought it was fine after answering your questions.
>>>>>> All good, I would like to finish the discusion. 
>>>>>>
>>>>>>> Yes, I have tested this with the rtems7 tools. It was possible to build 
>>>>>>> with
>>>>>>> the rtems7 tools
>>>>>>> before, however, the PROGRAM_PREFIX approach is better, since it allows
>>>>>>> also the
>>>>>>> build using vendor tools. We had some fixes for this recently:
>>>>>>>
>>>>>>> https://lists.rtems.org/pipermail/devel/2023-May/075321.html
>>>>>>>
>>>>>>> This is something the user need.
>>>>>> What if a user adds or uses a prefix that does not conform to the 
>>>>>> standard
>>>>>> format? I am assuming this is possible to do this, eg Gaisler's special
>>>>>> prefix?
>>>>>>
>>>>>> Possible breakage is
>>>>>> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457   ?
>>>>>>
>>>>>> Do we need to document any constraints around this option?
>>>>> There will be always problems left to fix.
>>>> I do not see this as a problem, I see an incomplete change pushed without 
>>>> the
>>>> review being completed.
>>> Sometimes it is not 100% clear when a review is finished.
>> Yes it is all a bit fragile and there is lots of guess work.
>>
>>>>> A basic build and the normal tests
>>>>> work fine with non-standard tools. For the Gaisler tools, you would need:
>>>>>
>>>>> PROGRAM_PREFIX = sparc-gaisler-rtems5-
>>>>>
>>>>> I guess the rld-cc.cpp will also have issues with a clang build.
>>>> Yes it would and libdl is a part of RTEMS and breaking it again is 
>>>> something I
>>>> would like to avoid. I consider the change incomplete because one part 
>>>> says use
>>>> PROGRAM_PREFIX to change the tools prefix however doing so may break other
>>>> parts. There is nothing to warn the user PROGRAM_PREFIX may not work as
>>>> expected.
>>> I don't use vendor tool chains, but it seems that some users would like to 
>>> use
>>> them. They were supported by the old build system, so a lacking support in 
>>> the
>>> new build system would be a regression. But if you don't like this change, 
>>> then
>>> we can also revert the patch.
>> I think the change is fine and I am not suggesting it is reverted. It is not
>> clear to me if more work is needed to complete what this has started because 
>> I
>> do not know where we stand with vendor tools.
>>
>> I think supporting vendor tools is something we should consider and either
>> accept it and sort out what is needed or we clearly state vendors are on 
>> their
>> own.
>>
>> Supporting vendor tools add something else we need to test and handle but it
>> lets vendors own the tools they create and it is clear to us when a user 
>> raises
>> a problem when using them.
> 
> The vendor tools support works now as good or bad as in RTEMS 5. If someone
> wants better support, then he/she should work on it. We can't make everything
> perfect, there are other things left to do for the RTEMS 6 release.

Should we document the extent of what we do support and what is missing?

And yes I agree with your comments however users are often not aware of this and
we end up fielding support related questions. I also do not think we need to do
much to make it work but I am not sure. How do you build gcc with a different
tools prefix?

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

Re: [PATCH 1/3] gitignore: Ignore clangd and clang-format files

[Chris Johns]

On 8/8/2023 4:07 pm, Chris Johns wrote:
> On 8/8/2023 1:05 pm, Utkarsh Verma wrote:
>> ---
>>  .gitignore | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/.gitignore b/.gitignore
>> index 8b28b186e1..d0144f6737 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -12,3 +12,7 @@ Makefile.in
>>  /testsuites/build/build
>>  /testsuites/build/wscript
>>  .waf*
>> +.clangd
>> +.clang-format
>> +compile_commands.json
>> +.cache/
> 
> What are these from?
> 
> Why add them to your $HOME/.gitignore?

Sorry ... that should be

Why not add them to your $HOME/.gitignore?

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

Re: [PATCH 1/3] gitignore: Ignore clangd and clang-format files

[Chris Johns]

On 8/8/2023 1:05 pm, Utkarsh Verma wrote:
> ---
>  .gitignore | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index 8b28b186e1..d0144f6737 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -12,3 +12,7 @@ Makefile.in
>  /testsuites/build/build
>  /testsuites/build/wscript
>  .waf*
> +.clangd
> +.clang-format
> +compile_commands.json
> +.cache/

What are these from?

Why add them to your $HOME/.gitignore?

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

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 7/8/2023 4:06 pm, Sebastian Huber wrote:
> On 07.08.23 00:25, Chris Johns wrote:
>> On 4/8/2023 4:39 pm, Sebastian Huber wrote:
>>> On 04.08.23 08:22, Chris Johns wrote:
>>>> On 4/8/2023 3:16 pm, Sebastian Huber wrote:
>>>>> On 04.08.23 00:27, Chris Johns wrote:
>>>>>> 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.
>>>>> Sorry I thought it was fine after answering your questions.
>>>> All good, I would like to finish the discusion. 
>>>>
>>>>> Yes, I have tested this with the rtems7 tools. It was possible to build 
>>>>> with
>>>>> the rtems7 tools
>>>>> before, however, the PROGRAM_PREFIX approach is better, since it allows
>>>>> also the
>>>>> build using vendor tools. We had some fixes for this recently:
>>>>>
>>>>> https://lists.rtems.org/pipermail/devel/2023-May/075321.html
>>>>>
>>>>> This is something the user need.
>>>> What if a user adds or uses a prefix that does not conform to the standard
>>>> format? I am assuming this is possible to do this, eg Gaisler's special 
>>>> prefix?
>>>>
>>>> Possible breakage is
>>>> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457  ?
>>>>
>>>> Do we need to document any constraints around this option?
>>> There will be always problems left to fix.
>> I do not see this as a problem, I see an incomplete change pushed without the
>> review being completed.
> 
> Sometimes it is not 100% clear when a review is finished.

Yes it is all a bit fragile and there is lots of guess work.

>>> A basic build and the normal tests
>>> work fine with non-standard tools. For the Gaisler tools, you would need:
>>>
>>> PROGRAM_PREFIX = sparc-gaisler-rtems5-
>>>
>>> I guess the rld-cc.cpp will also have issues with a clang build.
>> Yes it would and libdl is a part of RTEMS and breaking it again is something 
>> I
>> would like to avoid. I consider the change incomplete because one part says 
>> use
>> PROGRAM_PREFIX to change the tools prefix however doing so may break other
>> parts. There is nothing to warn the user PROGRAM_PREFIX may not work as 
>> expected.
> 
> I don't use vendor tool chains, but it seems that some users would like to use
> them. They were supported by the old build system, so a lacking support in the
> new build system would be a regression. But if you don't like this change, 
> then
> we can also revert the patch.

I think the change is fine and I am not suggesting it is reverted. It is not
clear to me if more work is needed to complete what this has started because I
do not know where we stand with vendor tools.

I think supporting vendor tools is something we should consider and either
accept it and sort out what is needed or we clearly state vendors are on their 
own.

Supporting vendor tools add something else we need to test and handle but it
lets vendors own the tools they create and it is clear to us when a user raises
a problem when using 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 4/8/2023 4:39 pm, Sebastian Huber wrote:
> On 04.08.23 08:22, Chris Johns wrote:
>> On 4/8/2023 3:16 pm, Sebastian Huber wrote:
>>> On 04.08.23 00:27, Chris Johns wrote:
>>>> 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.
>>>
>>> Sorry I thought it was fine after answering your questions.
>>
>> All good, I would like to finish the discusion. :)
>>
>>> Yes, I have tested this with the rtems7 tools. It was possible to build with
>>> the rtems7 tools
>>> before, however, the PROGRAM_PREFIX approach is better, since it allows 
>>> also the
>>> build using vendor tools. We had some fixes for this recently:
>>>
>>> https://lists.rtems.org/pipermail/devel/2023-May/075321.html
>>>
>>> This is something the user need.
>>
>> What if a user adds or uses a prefix that does not conform to the standard
>> format? I am assuming this is possible to do this, eg Gaisler's special 
>> prefix?
>>
>> Possible breakage is
>> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457 ?
>>
>> Do we need to document any constraints around this option?
> 
> There will be always problems left to fix. 

I do not see this as a problem, I see an incomplete change pushed without the
review being completed.

> A basic build and the normal tests
> work fine with non-standard tools. For the Gaisler tools, you would need:
> 
> PROGRAM_PREFIX = sparc-gaisler-rtems5-
> 
> I guess the rld-cc.cpp will also have issues with a clang build.

Yes it would and libdl is a part of RTEMS and breaking it again is something I
would like to avoid. I consider the change incomplete because one part says use
PROGRAM_PREFIX to change the tools prefix however doing so may break other
parts. There is nothing to warn the user PROGRAM_PREFIX may not work as 
expected.

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

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

[Chris Johns]

On 4/8/2023 4:47 pm, Sebastian Huber wrote:
> On 04.08.23 08:30, Chris Johns wrote:
>>> 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?
>>> Sorry, Joel is rushing for the RTEMS 6 release. The patch is from 19.05.23. 
>>> A CI
>>> system and pull requests would also help.
>> Ah yes and I have raised an 7 related RSB sources fetch that need to be fix 
>> as
>> well. My concern is release testing on hosts like MacOS M etc tend to find
>> issues if it has not been tested.
> 
> GitHub offers runners for macOS:
> 
> https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners
> 
> I don't understand why we don't use the GitHub services for the project. It is
> just a matter of adding a couple for text files to the repositories. You can
> still run your own GitLab stuff in parallel. It is not one or another. You can
> have both.

It is not a technical issue. Who legally owns the github account? It cannot be a
single person and it cannot be a company. It could be a foundation but ours is
not functioning enough to do this.

Individuals can always set up builders and post to the builds list and that is
no different to a private build server in a company but these is not part of the
project or under its control.

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

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

[Chris Johns]

On 4/8/2023 3:02 pm, Sebastian Huber wrote:
> On 04.08.23 00:53, Chris Johns wrote:
>> On 3/8/2023 5:36 pm, Sebastian Huber wrote:
>>> Ping.
>>
>> Which repo? Is this in the rtems-tools repo?
> 
> Yes, the rtems-tools.
> 

Thanks

> 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?
> 
> Sorry, Joel is rushing for the RTEMS 6 release. The patch is from 19.05.23. A 
> CI
> system and pull requests would also help.

Ah yes and I have raised an 7 related RSB sources fetch that need to be fix as
well. My concern is release testing on hosts like MacOS M etc tend to find
issues if it has not been tested.

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

Re: [PATCH] libdebugger: Restrict ARM architecture support

[Chris Johns]

On 4/8/2023 3:07 pm, Sebastian Huber wrote:
> On 04.08.23 00:43, Chris Johns wrote:
>> 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?
> 
> At least ARMv7-M and everything with Thumb 1.
> 

Does the rtems_debugger_target_configure fail in this patch for this arch?

>>> This fixes assembler errors at -O0.
>> How does it fix the assembler errors?
> 
> The unsupported assembly instructions are not issued by the compiler so that 
> the
> assembler is happy. This issue is open since 2020:
> 
> https://lists.rtems.org/pipermail/devel/2020-March/058432.html

Yes.

> 
> Since the gcov code coverage is generated using -O0, this is now a bigger 
> issue.
> 

Why is RPi showing issues? That is confusing me.

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

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 4/8/2023 3:16 pm, Sebastian Huber wrote:
> On 04.08.23 00:27, Chris Johns wrote:
>> 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.
> 
> Sorry I thought it was fine after answering your questions. 

All good, I would like to finish the discusion. :)

> Yes, I have tested this with the rtems7 tools. It was possible to build with 
> the rtems7 tools
> before, however, the PROGRAM_PREFIX approach is better, since it allows also 
> the
> build using vendor tools. We had some fixes for this recently:
> 
> https://lists.rtems.org/pipermail/devel/2023-May/075321.html
> 
> This is something the user need.

What if a user adds or uses a prefix that does not conform to the standard
format? I am assuming this is possible to do this, eg Gaisler's special prefix?

Possible breakage is
https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457 ?

Do we need to document any constraints around this option?

> I have problems to send test reports by e-mail:

Anything Amar or I can help with?

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

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

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

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: [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

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: [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: [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: [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: [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: [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: [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

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

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

[Chris Johns]

On 14/6/2023 6:08 pm, Philip Kirkpatrick wrote:
> This patch adds support for running RTEMS on the RPU (cortex R5) cores of the
> ZynqMP. 

Thanks for submitting this BSP. It is exciting to see this work and support
being added.

How different are the ZynqMP RPU cores and the ones on the Versal?

I have not looked in detail but I know they are both R5 devices and I think we
should be able to reuse this support. Is placing the RPU pieces under the ZynqMP
sources what we want or should we consider how we would reuse the RPU BSP on
other Xilinx devices?

I am leading with this question without reviewing the sources in detail so I
apologise for this. I am happy to look at Versal support so I am not asking that
to be done.

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

Re: [PATCH 1/1] eng: Fix builds for newer Sphinx versions (>=7)

[Chris Johns]

Pushed. I added a close for the ticket to the commit message.

Thank you for looking into this and fixing it.

Chris


On 14/6/2023 3:36 pm, Utkarsh Verma wrote:
> The current Sphinx theme depends on the `style` parameter which got
> deprecated in v5.1 and finally got removed in v7. Now, the `styles` key
> should be preferred which is a list of stylesheets. This commit
> implements this change.
> ---
>  common/sphinx_rtd_theme_rtems/layout.html | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/common/sphinx_rtd_theme_rtems/layout.html 
> b/common/sphinx_rtd_theme_rtems/layout.html
> index 0fe6c65..91d67b5 100644
> --- a/common/sphinx_rtd_theme_rtems/layout.html
> +++ b/common/sphinx_rtd_theme_rtems/layout.html
> @@ -67,7 +67,9 @@
>{%- endblock %}
>  
>{# CSS #}
> +  {% for style in styles %}
> type="text/css" />
> +  {% endfor %}
> type="text/css" />
>{%- for css in css_files %}
>  {%- if css|attr("rel") %}
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel