Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

[Christian MAUDERER]

Hello,

I don't object to clear rules. At the moment it's a bit of a mix. Some 
examples of what I have found (mainly in PowerPC):


Above the copyright line:

https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors.S
https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors_init.c
https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/irq.c
https://git.rtems.org/rtems/tree/bsps/powerpc/include/libcpu/irq.h

Mixed in the header somewhere:

https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/bspstart.c


Am 21.07.21 um 07:51 schrieb Sebastian Huber:

On 21/07/2021 02:46, Chris Johns wrote:

On 21/7/21 6:47 am, Gedare Bloom wrote:

This seems fine to me. We don't have any standard way to document this
kind of attribution. However, we have had individual authors add their
names below their company's copyright. It might make sense to put the
sponsorship part beneath the copyright of the sponsored
company/person?


Make sense. The copyright block should be limited to just copyrights 
and sponsor
acknowledgements should in a separate block, maybe after the license 
block.


Yes, I also think it should be outside the license comment block.




Not a big deal, but it might help for some kind of
consistent guidance if we do this more in the future.


I think we need some guidelines. I do not agree with URL links, email 
addresses,
phone numbers or street addreses appearing in the source. I also think 
a sponsor
acknowledgement is never updated or changed even if a company changes 
name. What
I am not sure about is the areas of the source we allow this to happen 
in, ie

score ...?


We could add some text here:

https://docs.rtems.org/branches/master/eng/coding-file-hdr.html



Without discussing it with Onto: An alternative to attribution in the 
code could be an attribution page in the manuals where we can collect 
such notes. That would avoid scattering them throughout the code. It 
would also make it easier to (for example) attribute to supporters that 
maybe don't fund coding but other activities like infrastructure.


We could add "User Applications" in a similar section. At the moment 
these are in a TBR wiki area: https://devel.rtems.org/wiki/TBR/UserApp


Best regards

Christian
--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

[Chris Johns]

On 21/7/21 5:34 pm, Christian MAUDERER wrote:
> Hello Chris,
> 
> Am 21.07.21 um 09:22 schrieb Chris Johns:
>> On 21/7/21 5:05 pm, Christian MAUDERER wrote:
>>> Hello,
>>>
>>> I don't object to clear rules. At the moment it's a bit of a mix.
>>
>> Yes I understand and I think the line you posted in the patch is fine as is, 
>> it
>> just needs to be separate from the license text because it could taint it 
>> and we
>> need to avoid that.
>>
>>> Some examples
>>> of what I have found (mainly in PowerPC):
>>>
>>> Above the copyright line:
>>>
>>> https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors.S
>>> https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors_init.c
>>> https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/irq.c
>>> https://git.rtems.org/rtems/tree/bsps/powerpc/include/libcpu/irq.h
>>
>> Yes there are some legacy comments. I would not touch those. We are more
>> informed on how we handle these things these days.
>>
>>> Mixed in the header somewhere:
>>>
>>> https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/bspstart.c
>>>
>>> Am 21.07.21 um 07:51 schrieb Sebastian Huber:
 On 21/07/2021 02:46, Chris Johns wrote:
> On 21/7/21 6:47 am, Gedare Bloom wrote:
>> This seems fine to me. We don't have any standard way to document this
>> kind of attribution. However, we have had individual authors add their
>> names below their company's copyright. It might make sense to put the
>> sponsorship part beneath the copyright of the sponsored
>> company/person?
>
> Make sense. The copyright block should be limited to just copyrights and
> sponsor
> acknowledgements should in a separate block, maybe after the license 
> block.

 Yes, I also think it should be outside the license comment block.

>
>> Not a big deal, but it might help for some kind of
>> consistent guidance if we do this more in the future.
>
> I think we need some guidelines. I do not agree with URL links, email
> addresses,
> phone numbers or street addreses appearing in the source. I also think a
> sponsor
> acknowledgement is never updated or changed even if a company changes 
> name.
> What
> I am not sure about is the areas of the source we allow this to happen 
> in, ie
> score ...?

 We could add some text here:

 https://docs.rtems.org/branches/master/eng/coding-file-hdr.html

>>>
>>> Without discussing it with Onto: An alternative to attribution in the code 
>>> could
>>> be an attribution page in the manuals where we can collect such notes. That
>>> would avoid scattering them throughout the code. It would also make it 
>>> easier to
>>> (for example) attribute to supporters that maybe don't fund coding but other
>>> activities like infrastructure.
>>
>> Sorry, collecting in a manual is a step to far and I would not support it. 
>> Some
>> companies have tight marketing requirements and trademarks for placement of
>> their company details in manuals or printed material and we need to keep well
>> clear of this. There are sponsors of RTEMS who require nothing is said, ever.
> 
> Yes. Most companies don't want to be mentioned. I was a bit surprised that 
> Onto
> asked for it ;-)

I am OK with this.

>> There is a legal aspect to this that I am not sure about yet. What happens 
>> if a
>> company complains about the addition?
> 
> I would only add companies that ask for it. I think most paid projects have 
> some
> kind of contract where that could be clarified right from the beginning.

You know this but I do not. We need a simple way to handle this.

> For
> sponsors without a project, it could be done with some kind of "yes, I want to
> be added" field on a donation page. I assume that's how other projects handle
> that kind of stuff.

Yes we need a donate page but that is a separate topic.

> 
> One example for a project with a big supporters list:
> 
> https://metabrainz.org/supporters
> 
> The just added a "I would like the donation to be anonymous" to the donate 
> page:
> 
> https://metabrainz.org/donate
> 

Yes.

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

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

[Christian MAUDERER]

Am 21.07.21 um 09:34 schrieb Christian MAUDERER:

Hello Chris,

Am 21.07.21 um 09:22 schrieb Chris Johns:

On 21/7/21 5:05 pm, Christian MAUDERER wrote:

Hello,

I don't object to clear rules. At the moment it's a bit of a mix.


Yes I understand and I think the line you posted in the patch is fine 
as is, it
just needs to be separate from the license text because it could taint 
it and we

need to avoid that.


Some examples
of what I have found (mainly in PowerPC):

Above the copyright line:

https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors.S
https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors_init.c
https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/irq.c
https://git.rtems.org/rtems/tree/bsps/powerpc/include/libcpu/irq.h


Yes there are some legacy comments. I would not touch those. We are more
informed on how we handle these things these days.


Mixed in the header somewhere:

https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/bspstart.c

Am 21.07.21 um 07:51 schrieb Sebastian Huber:

On 21/07/2021 02:46, Chris Johns wrote:

On 21/7/21 6:47 am, Gedare Bloom wrote:
This seems fine to me. We don't have any standard way to document 
this
kind of attribution. However, we have had individual authors add 
their

names below their company's copyright. It might make sense to put the
sponsorship part beneath the copyright of the sponsored
company/person?


Make sense. The copyright block should be limited to just 
copyrights and sponsor
acknowledgements should in a separate block, maybe after the 
license block.


Yes, I also think it should be outside the license comment block.




Not a big deal, but it might help for some kind of
consistent guidance if we do this more in the future.


I think we need some guidelines. I do not agree with URL links, 
email addresses,
phone numbers or street addreses appearing in the source. I also 
think a sponsor
acknowledgement is never updated or changed even if a company 
changes name. What
I am not sure about is the areas of the source we allow this to 
happen in, ie

score ...?


We could add some text here:

https://docs.rtems.org/branches/master/eng/coding-file-hdr.html



Without discussing it with Onto: An alternative to attribution in the 
code could
be an attribution page in the manuals where we can collect such 
notes. That
would avoid scattering them throughout the code. It would also make 
it easier to
(for example) attribute to supporters that maybe don't fund coding 
but other

activities like infrastructure.


Sorry, collecting in a manual is a step to far and I would not support 
it. Some
companies have tight marketing requirements and trademarks for 
placement of
their company details in manuals or printed material and we need to 
keep well
clear of this. There are sponsors of RTEMS who require nothing is 
said, ever.


Yes. Most companies don't want to be mentioned. I was a bit surprised 
that Onto asked for it ;-)




There is a legal aspect to this that I am not sure about yet. What 
happens if a

company complains about the addition?


I would only add companies that ask for it. I think most paid projects 
have some kind of contract where that could be clarified right from the 
beginning. For sponsors without a project, it could be done with some 
kind of "yes, I want to be added" field on a donation page. I assume 
that's how other projects handle that kind of stuff.


One example for a project with a big supporters list:

https://metabrainz.org/supporters

The just added a "I would like the donation to be anonymous" to the 
donate page:


https://metabrainz.org/donate

Best regards

Christian


PS: I assumed that adding it to the manual would be a bigger discussion 
and I don't want to really open that can of worms for this case. It's 
only a suggestion that we could think about something like that too. 
It's not that uncommon for open source projects to collect supporters or 
users somewhere.






Chris





--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

[Chris Johns]

On 21/7/21 3:51 pm, Sebastian Huber wrote:
> On 21/07/2021 02:46, Chris Johns wrote:
>> I think we need some guidelines. I do not agree with URL links, email 
>> addresses,
>> phone numbers or street addreses appearing in the source. I also think a 
>> sponsor
>> acknowledgement is never updated or changed even if a company changes name. 
>> What
>> I am not sure about is the areas of the source we allow this to happen in, ie
>> score ...?
> 
> We could add some text here:
> 
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html
> 

Yes. I will consider this and post an initial approach we can discuss in detail.

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

Re: [PATCH] bsp: Remove fatal from exit(0). Add extended heap error output

[Chris Johns]

On 21/7/21 3:37 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> thanks, this is a nice improvement.

It helps find the corruption with a watch point.

> On 21/07/2021 07:17, chr...@rtems.org wrote:
>> --- a/bsps/shared/start/bspfatal-default.c
>> +++ b/bsps/shared/start/bspfatal-default.c
>> @@ -22,15 +22,24 @@ void bsp_fatal_extension(
>>   {
>>     #if BSP_VERBOSE_FATAL_EXTENSION
>>   Thread_Control *executing;
>> +    const char* TYPE = "*** FATAL ***\n";
>> +    const char* type = "fatal";
>> +
>> +    if ( source == RTEMS_FATAL_SOURCE_EXIT ) {
>> +  TYPE = "";
> 
> It would be good to still have a unique pattern which starts the fatal 
> extension
> message.  The "***" is also used for the test begin/end marker. What about 
> "***
> SYSTEM TERMINATED ***"?

I considered this but I was concerned about the difference not being clear.
Maybe I overstepped. The patch gives us:

exit source: 5 (RTEMS_FATAL_SOURCE_EXIT)
exit code: 0 (0x)
RTEMS version: 6.0.0.87609bacd323eef1f3f4d6620ce42e7e5309ad10
RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
executing thread ID: 0x08a010001
executing thread name: UI1

and with the banner text:

*** EXIT ***
exit source: 5 (RTEMS_FATAL_SOURCE_EXIT)
exit code: 0 (0x)
RTEMS version: 6.0.0.87609bacd323eef1f3f4d6620ce42e7e5309ad10
RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
executing thread ID: 0x08a010001
executing thread name: UI1

It is easy to bend any direction here so maybe we wait for Joel to comment
before I make a v2 patch.

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

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

[Chris Johns]

On 21/7/21 5:05 pm, Christian MAUDERER wrote:
> Hello,
> 
> I don't object to clear rules. At the moment it's a bit of a mix. 

Yes I understand and I think the line you posted in the patch is fine as is, it
just needs to be separate from the license text because it could taint it and we
need to avoid that.

> Some examples
> of what I have found (mainly in PowerPC):
> 
> Above the copyright line:
> 
> https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors.S
> https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors_init.c
> https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/irq.c
> https://git.rtems.org/rtems/tree/bsps/powerpc/include/libcpu/irq.h

Yes there are some legacy comments. I would not touch those. We are more
informed on how we handle these things these days.

> Mixed in the header somewhere:
> 
> https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/bspstart.c
> 
> Am 21.07.21 um 07:51 schrieb Sebastian Huber:
>> On 21/07/2021 02:46, Chris Johns wrote:
>>> On 21/7/21 6:47 am, Gedare Bloom wrote:
 This seems fine to me. We don't have any standard way to document this
 kind of attribution. However, we have had individual authors add their
 names below their company's copyright. It might make sense to put the
 sponsorship part beneath the copyright of the sponsored
 company/person?
>>>
>>> Make sense. The copyright block should be limited to just copyrights and 
>>> sponsor
>>> acknowledgements should in a separate block, maybe after the license block.
>>
>> Yes, I also think it should be outside the license comment block.
>>
>>>
 Not a big deal, but it might help for some kind of
 consistent guidance if we do this more in the future.
>>>
>>> I think we need some guidelines. I do not agree with URL links, email 
>>> addresses,
>>> phone numbers or street addreses appearing in the source. I also think a 
>>> sponsor
>>> acknowledgement is never updated or changed even if a company changes name. 
>>> What
>>> I am not sure about is the areas of the source we allow this to happen in, 
>>> ie
>>> score ...?
>>
>> We could add some text here:
>>
>> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html
>>
> 
> Without discussing it with Onto: An alternative to attribution in the code 
> could
> be an attribution page in the manuals where we can collect such notes. That
> would avoid scattering them throughout the code. It would also make it easier 
> to
> (for example) attribute to supporters that maybe don't fund coding but other
> activities like infrastructure.

Sorry, collecting in a manual is a step to far and I would not support it. Some
companies have tight marketing requirements and trademarks for placement of
their company details in manuals or printed material and we need to keep well
clear of this. There are sponsors of RTEMS who require nothing is said, ever.

There is a legal aspect to this that I am not sure about yet. What happens if a
company complains about the addition?

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

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

[Christian MAUDERER]

Hello Chris,

Am 21.07.21 um 09:22 schrieb Chris Johns:

On 21/7/21 5:05 pm, Christian MAUDERER wrote:

Hello,

I don't object to clear rules. At the moment it's a bit of a mix.


Yes I understand and I think the line you posted in the patch is fine as is, it
just needs to be separate from the license text because it could taint it and we
need to avoid that.


Some examples
of what I have found (mainly in PowerPC):

Above the copyright line:

https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors.S
https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors_init.c
https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/irq.c
https://git.rtems.org/rtems/tree/bsps/powerpc/include/libcpu/irq.h


Yes there are some legacy comments. I would not touch those. We are more
informed on how we handle these things these days.


Mixed in the header somewhere:

https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/bspstart.c

Am 21.07.21 um 07:51 schrieb Sebastian Huber:

On 21/07/2021 02:46, Chris Johns wrote:

On 21/7/21 6:47 am, Gedare Bloom wrote:

This seems fine to me. We don't have any standard way to document this
kind of attribution. However, we have had individual authors add their
names below their company's copyright. It might make sense to put the
sponsorship part beneath the copyright of the sponsored
company/person?


Make sense. The copyright block should be limited to just copyrights and sponsor
acknowledgements should in a separate block, maybe after the license block.


Yes, I also think it should be outside the license comment block.




Not a big deal, but it might help for some kind of
consistent guidance if we do this more in the future.


I think we need some guidelines. I do not agree with URL links, email addresses,
phone numbers or street addreses appearing in the source. I also think a sponsor
acknowledgement is never updated or changed even if a company changes name. What
I am not sure about is the areas of the source we allow this to happen in, ie
score ...?


We could add some text here:

https://docs.rtems.org/branches/master/eng/coding-file-hdr.html



Without discussing it with Onto: An alternative to attribution in the code could
be an attribution page in the manuals where we can collect such notes. That
would avoid scattering them throughout the code. It would also make it easier to
(for example) attribute to supporters that maybe don't fund coding but other
activities like infrastructure.


Sorry, collecting in a manual is a step to far and I would not support it. Some
companies have tight marketing requirements and trademarks for placement of
their company details in manuals or printed material and we need to keep well
clear of this. There are sponsors of RTEMS who require nothing is said, ever.


Yes. Most companies don't want to be mentioned. I was a bit surprised 
that Onto asked for it ;-)




There is a legal aspect to this that I am not sure about yet. What happens if a
company complains about the addition?


I would only add companies that ask for it. I think most paid projects 
have some kind of contract where that could be clarified right from the 
beginning. For sponsors without a project, it could be done with some 
kind of "yes, I want to be added" field on a donation page. I assume 
that's how other projects handle that kind of stuff.


One example for a project with a big supporters list:

https://metabrainz.org/supporters

The just added a "I would like the donation to be anonymous" to the 
donate page:


https://metabrainz.org/donate

Best regards

Christian



Chris



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

[Pavel Pisa]

Hello Vijay,

thanks of the status.

On Wednesday 21 of July 2021 07:16:51 Vijay Kumar Banerjee wrote:
> Hi Pavel,
>
> On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa  wrote:
> > Is it devel branch of  Vijay Kumar Banerjee's
> > repo
> >
> >   https://git.rtems.org/vijay/rtems-lwip.git/
>
> Right now yes. Once this is mature, it will probably be pushed to the
> top directory.
>
> > If so, it would worth to put that on the top
> > of LwIP RTEMS info page to guide people interested
> > to live work and not lose time in another
> > abandonned attempts
> >
> >   https://devel.rtems.org/wiki/Packages/LWIP
>
> Thanks, I'll add a note there.
>
> > Addition of pointers to STM WIP to some
> > central place would worth too with
> > pointer to the instructions or instructions
> > included...
>
> I haven't tested it myself. Robin is working on this one and might be
> able to add the instructions. But this is supposed to be merged into
> the repo you mentioned above.

Great that there is the common merge place.


> > Generally I am curious what works and where
> > are problems. I do not expect to have time or
> > find students this summer but I try to offer
> > project as theses and next summer and there
> > chance (small) that I find some studnet
> > to participate.
>
> I am currently actively working on the lwip port to get it working
> with at least a few boards, along with a streamlined build system. I
> could only get the BBB running with a telnetd application that I added
> in the test/ directory in the rtems-lwip repository. I used the
> drivers from TI for BBB.

OK, I have some access to BBB so when my or some studnet
time allows we can test it on this target.
I am more personally interested to TMS570.
I think that I can find some time for testing on TMS570LS3137
if the instructions and code is declared to worth to test.
I hope that I have all tools for this setup.

=
Side note to TMS570 FEE CTU code (if there is interest,
I it would worth to move to separate thread)

By the way, the way my former colleagues who left faculty
stopped blocking (after many years) TMS570 Rapid Prototyping
Platform code
  http://rtime.felk.cvut.cz/rpp-tms570/
and changed master branch license to MIT (The work has been
exploited to gain money from their industrial partners and has
little value for them now). Code was and is licensed under our
faculty name and I can legally show it to third parties now
and  try to find arrangement to share my and my students effort
with community.

There is XCP https://en.wikipedia.org/wiki/XCP_(protocol)
loader implemented on FreeRTOS base which allows to update
firmware over ETHERNET so it can be used as boot block for
RTEMS. It can make RTEMS support testing and even continuous
integration much easier. When RTEMS is run from SDRAM it
would prevent Flash wear-out, important for TMS570,
because guaranteed erase cycles are limited.

Then there is support for lot of the TMS570 peripherals
in the state twisted with HalCoGen, not directly usable,
but valuable as reference. Lot of Matlab/Simulink glue
which can be reused with minimal changes and  N2HET and
DMA based "HW" implementation of time triggered CAN
transfers with clock scaling and synchronization.

So if there is interest, I can provide more information
and collect it in RTEMS Wiki or on 

  Open Technologies Research Education and Exchange Services
  https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

pages, which are intended primarily for cooperation with
our students.

As for original RTIME wiki and documentation (even documenting
RTEMS and GNU/Linux work shared from my company, done with studnets,
myself at home), I do not expect to contribute to it any more.
Even that substantial part is result of my 25 years of investent
to that group but its leaders took it with them to another
place with end expressed strong will/command to not contact
"their" people anymore. Most of them have left them anyway
so no problem to ask them for advises and help directly.
=
Back to LwIP

Extending loader and OpenOCD support for TMS570LC4357
is another target long term on my list.

Back to LwIP, I see some your effort to implement
select  sowwakeup(so); and sorwakeup() based
on some code copied from BSD stack

  https://git.rtems.org/vijay/rtems-lwip.git/tree/netinet?h=devel

I think that there would be problem to integrate
select cleanly when LwIP SOCK API is used.
If we limit select only on sockets, then the option
is to translate FD sets to LwIP struct *socket and
then use LwIP select implementation. But I do not like
this approach. I would prefer if the select mechanism
is part of RTEMS core, allows character devices (UART...)
support and stack provides only mechanism how to register
into this generic support.

I think that such arrangement would not be problem with LwIP
when NETCON API is used. But select support in RTEMS
core could be 

Re: [PATCH 00/41] Document, enhance, and test Interrupt Manager Extension

[Sebastian Huber]

Hello,

are there any comments with respect to the API additions and the 
documentation changes in general?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

[Christian MAUDERER]

Am 21.07.21 um 10:31 schrieb Chris Johns:

On 21/7/21 5:34 pm, Christian MAUDERER wrote:

Hello Chris,

Am 21.07.21 um 09:22 schrieb Chris Johns:

On 21/7/21 5:05 pm, Christian MAUDERER wrote:

Hello,

I don't object to clear rules. At the moment it's a bit of a mix.


Yes I understand and I think the line you posted in the patch is fine as is, it
just needs to be separate from the license text because it could taint it and we
need to avoid that.


Some examples
of what I have found (mainly in PowerPC):

Above the copyright line:

https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors.S
https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/vectors_init.c
https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/irq.c
https://git.rtems.org/rtems/tree/bsps/powerpc/include/libcpu/irq.h


Yes there are some legacy comments. I would not touch those. We are more
informed on how we handle these things these days.


Mixed in the header somewhere:

https://git.rtems.org/rtems/tree/bsps/powerpc/ss555/start/bspstart.c

Am 21.07.21 um 07:51 schrieb Sebastian Huber:

On 21/07/2021 02:46, Chris Johns wrote:

On 21/7/21 6:47 am, Gedare Bloom wrote:

This seems fine to me. We don't have any standard way to document this
kind of attribution. However, we have had individual authors add their
names below their company's copyright. It might make sense to put the
sponsorship part beneath the copyright of the sponsored
company/person?


Make sense. The copyright block should be limited to just copyrights and
sponsor
acknowledgements should in a separate block, maybe after the license block.


Yes, I also think it should be outside the license comment block.




Not a big deal, but it might help for some kind of
consistent guidance if we do this more in the future.


I think we need some guidelines. I do not agree with URL links, email
addresses,
phone numbers or street addreses appearing in the source. I also think a
sponsor
acknowledgement is never updated or changed even if a company changes name.
What
I am not sure about is the areas of the source we allow this to happen in, ie
score ...?


We could add some text here:

https://docs.rtems.org/branches/master/eng/coding-file-hdr.html



Without discussing it with Onto: An alternative to attribution in the code could
be an attribution page in the manuals where we can collect such notes. That
would avoid scattering them throughout the code. It would also make it easier to
(for example) attribute to supporters that maybe don't fund coding but other
activities like infrastructure.


Sorry, collecting in a manual is a step to far and I would not support it. Some
companies have tight marketing requirements and trademarks for placement of
their company details in manuals or printed material and we need to keep well
clear of this. There are sponsors of RTEMS who require nothing is said, ever.


Yes. Most companies don't want to be mentioned. I was a bit surprised that Onto
asked for it ;-)


I am OK with this.


There is a legal aspect to this that I am not sure about yet. What happens if a
company complains about the addition?


I would only add companies that ask for it. I think most paid projects have some
kind of contract where that could be clarified right from the beginning.


You know this but I do not. We need a simple way to handle this.


For
sponsors without a project, it could be done with some kind of "yes, I want to
be added" field on a donation page. I assume that's how other projects handle
that kind of stuff.


Yes we need a donate page but that is a separate topic.



One example for a project with a big supporters list:

https://metabrainz.org/supporters

The just added a "I would like the donation to be anonymous" to the donate page:

https://metabrainz.org/donate



Yes.

Chris



OK. If I understood you correctly in the other mail: You want to post a 
draft for some guidelines? I'll wait for these and adapt the patch 
accordingly.


Best regards

Christian
--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3 2/5] rtems-exeinfo.cpp: Restore ostream format

[Ryan Long]

CID 1503006: Not restoring ostream format
CID 1503007: Not restoring ostream format

Used a variable to store the format of the ostream before any changes,
and copied what was originally there back into the stream before
returning from the function.

Closes #4469
---
 linkers/rtems-exeinfo.cpp | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
index 6e92206..c9bf5b6 100644
--- a/linkers/rtems-exeinfo.cpp
+++ b/linkers/rtems-exeinfo.cpp
@@ -47,11 +47,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifndef HAVE_KILL
 #define kill(p,s) raise(s)
 #endif
 
+typedef rtems::utils::ostream_guard ostream_guard;
+
 namespace rld
 {
   namespace exeinfo
@@ -366,6 +369,7 @@ namespace rld
*/
 
   rld::strings all_flags;
+  ostream_guard old_state( std::cout );
 
   size_t source_max = 0;
 
@@ -632,6 +636,8 @@ namespace rld
 
 void image::output_tls ()
 {
+  ostream_guard old_state( std::cout );
+
   symbols::symbol* tls_data_begin = symbols.find_global("_TLS_Data_begin");
   symbols::symbol* tls_data_end = symbols.find_global("_TLS_Data_end");
   symbols::symbol* tls_data_size = symbols.find_global("_TLS_Data_size");
-- 
1.8.3.1

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

[PATCH v3 3/5] CoverageMapBase.cc: Restore ostream format

[Ryan Long]

CID 1503022: Not restoring ostream format

Save format of stream before changing it, and change it back before returning.

Closes #4470
---
 tester/covoar/CoverageMapBase.cc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tester/covoar/CoverageMapBase.cc b/tester/covoar/CoverageMapBase.cc
index f0b5890..4de9307 100644
--- a/tester/covoar/CoverageMapBase.cc
+++ b/tester/covoar/CoverageMapBase.cc
@@ -12,9 +12,12 @@
 #include 
 
 #include 
+#include 
 
 #include "CoverageMapBase.h"
 
+typedef rtems::utils::ostream_guard ostream_guard;
+
 namespace Coverage {
 
   AddressInfo::AddressInfo ()
@@ -75,6 +78,8 @@ namespace Coverage {
 
   void AddressRange::dump (std::ostream& out, bool show_slots) const
   {
+ostream_guard old_state( out );
+
 out << std::hex << std::setfill('0')
 << "Address range: low = " << std::setw(8) << lowAddress
 << " high = " << std::setw(8) << highAddress
@@ -99,6 +104,7 @@ namespace Coverage {
 << std::endl;
   }
 }
+
   }
 
   CoverageMapBase::CoverageMapBase(
-- 
1.8.3.1

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

[PATCH v3 4/5] ReportsHtml.cc: Restore ostream format

[Ryan Long]

CID 1505939: Not restoring ofstream format

Save format of stream before changing it, and change it back before returning.

Closes #4471
---
 tester/covoar/ReportsHtml.cc | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tester/covoar/ReportsHtml.cc b/tester/covoar/ReportsHtml.cc
index 53ee0c1..e276732 100644
--- a/tester/covoar/ReportsHtml.cc
+++ b/tester/covoar/ReportsHtml.cc
@@ -6,6 +6,7 @@
 #include 
 
 #include 
+#include 
 
 #include "ReportsHtml.h"
 #include "app_common.h"
@@ -13,6 +14,8 @@
 #include "DesiredSymbols.h"
 #include "ObjdumpProcessor.h"
 
+typedef rtems::utils::ostream_guard ostream_guard;
+
 #if 0
 #define TABLE_HEADER_CLASS \
   " table-autopage:10 table-page-number:pagenum table-page-count:pages "
@@ -724,6 +727,7 @@ namespace Coverage {
 const SymbolInformation& symbolInfo
   )
   {
+ostream_guard old_state( report );
 
 // Mark the background color different for odd and even lines.
 if ( ( count % 2 ) != 0 ) {
@@ -818,6 +822,7 @@ namespace Coverage {
 }
 
 report << "" << std::endl;
+
 return true;
   }
 
-- 
1.8.3.1

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

[PATCH v3 1/5] rtems-utils.h: Create ostream_guard

[Ryan Long]

---
 rtemstoolkit/rtems-utils.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/rtemstoolkit/rtems-utils.h b/rtemstoolkit/rtems-utils.h
index 4ce9c68..c4d227c 100644
--- a/rtemstoolkit/rtems-utils.h
+++ b/rtemstoolkit/rtems-utils.h
@@ -47,6 +47,26 @@ namespace rtems
boolreal = false,
size_t  line_length = 16,
uint32_toffset = 0);
+
+/*
+ * Save and restore the output stream's settings.
+ */
+struct ostream_guard {
+  std::ostream&   o;
+  std::ios_base::fmtflags flags;
+
+  ostream_guard (std::ostream& o_)
+: o (o_),
+  flags (o_.flags ())
+  {
+  }
+
+  ~ostream_guard ()
+  {
+ o.flags( flags );
+  }
+};
+
   }
 }
 
-- 
1.8.3.1

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

[PATCH v3 5/5] ReportsText.cc: Restore ostream format

[Ryan Long]

CID 1505940: Not restoring ostream format

Save format of stream before changing it, and change it back before returning.

Closes #4472
---
 tester/covoar/ReportsText.cc | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tester/covoar/ReportsText.cc b/tester/covoar/ReportsText.cc
index 146fc35..c4a5dbc 100644
--- a/tester/covoar/ReportsText.cc
+++ b/tester/covoar/ReportsText.cc
@@ -10,6 +10,9 @@
 #include "Explanations.h"
 #include "ObjdumpProcessor.h"
 
+#include 
+
+typedef rtems::utils::ostream_guard ostream_guard;
 
 namespace Coverage {
 
@@ -145,6 +148,8 @@ bool ReportsText::PutCoverageLine(
 {
   const Coverage::Explanation* explanation;
 
+  ostream_guard oldState( report );
+
   report << "" << std::endl
  << "Index: " << range.id << std::endl
  << "Symbol   : " << symbolName
-- 
1.8.3.1

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

Re: Building a library for use with RTEMS via CMake

[Robin Müller]

tems-cmake uses the toolchain file functionality which takes care of
finding the RTEMS compiler and add the required flags for RTEMS.
If the CMakeLists.txt belongs to a library, I would guess you will compile
it as part of a  (dummy) project and you can still edit the top
CMakeLists.txt?
If you still need a custom toolchain file you can probably write your own
toolchain file and then include the rtems-cmake toolchain file but I have
never
tested doing something like that.

As long as your library does not require setting another toolchain file as
well, compiling it should not be an issue.

Kind Regards
Robin

On Wed, 21 Jul 2021 at 16:48, Robin Müller 
wrote:

> rtems-cmake uses the toolchain file functionality which takes care of
> finding the RTEMS compiler and add the required flags for RTEMS.
> If the CMakeLists.txt belongs to a library, I would guess you will compile
> it as part of a  (dummy) project and you can still edit the top
> CMakeLists.txt?
> If you still need a custom toolchain file you can probably write your own
> toolchain file and then include the rtems-cmake toolchain file but I have
> never
> tested doing something like that.
>
> As long as your library does not require setting another toolchain file as
> well, compiling it should not be an issue.
>
> Kind Regards
> Robin
>
> On Tue, 20 Jul 2021 at 13:07,  wrote:
>
>> Hey guys,
>>
>>
>>
>> that was so far very helpful in understanding the problem in more depth.
>>
>> Putting in the right flags at least reduced the linker errors by nearly
>> 99% or so, Thanks.
>>
>> Maybe I am on the right path now and just need to tweak it a bit to make
>> it work.
>>
>>
>>
>> The rtems-cmake repository looks also very promising to me, I surely have
>> to dig deeper into the processes going on there.
>>
>> Problem is that I should (ideally) not change the CMakeLists.txt from the
>> library so it stays independent.
>>
>> Do you have any thoughts on that Robin?
>>
>> Do you think wrapping the library CMakeLists.txt in another one which
>> then uses the repository might work?
>>
>>
>>
>> But I realized that I have missed some information while explaining this
>> issue.
>>
>> The RTEMS application itself is built with SCons and therefore the
>> desired build environment (flags and so forth) is already defined within a
>> python dictionary.
>>
>> Now we need to somehow build the library via CMake using the established
>> environment, install and link against it via SCons.
>>
>> Do you have worked with something  like this before?
>>
>>
>>
>> Best regards
>>
>> André
>>
>>
>>
>> *Von:* devel  *Im Auftrag von *Robin Müller
>> *Gesendet:* Dienstag, 20. Juli 2021 11:46
>> *An:* Michael Davidsaver ; devel@rtems.org
>> *Betreff:* Re: Building a library for use with RTEMS via CMake
>>
>>
>>
>> I managed to compile our project with CMake, using this repository:
>> https://github.com/spacefisch/rtems-cmake
>>
>> It uses the pkg-config files to set up the cross compiler given the BSP
>> and RTEMS prefix information.
>>
>>
>>
>> Maybe this can help you
>>
>>
>>
>> Kind Regards
>>
>> Robin
>>
>>
>>
>> On Tue, 20 Jul 2021 at 00:50, Michael Davidsaver 
>> wrote:
>>
>> On 7/19/21 6:17 AM, andre.nahrw...@dlr.de wrote:
>> > Hello,
>> >
>> > I have built RTEMS 5 and its tools for the Xilinx Zynq Zedboard and
>> installed the BSP and tools at a certain position on my machine.
>> > The tools are added to the PATH variable and RTEMS_BSPS is also
>> available in the environment.
>> >
>> > Now we need to build a library for the use with RTEMS via CMake.
>> > For this we wanted to use the toolchain files.
>> > Does anybody know how to correctly setup such a toolchain file using
>> the RTEMS compiler?
>> >
>> > We managed to get a toolchain file working which at least built the
>> library.
>> > But when we wanted to link to this library during compilation of a
>> RTEMS application we got a bunch of errors due to undefined references to
>> standard library functions.
>> > Does anybody has a clue where this might origin from?
>>
>> As it happens, I went through this exercise recently with libevent.
>> The main obstacle for me was that the CMake try_compile() command
>> actually tries to link an executable.  With RTEMS 5 this can't be
>> done generically without also adding '-lrtemsdefaultconfig'.
>>
>> eg.
>>
>> > string(APPEND CMAKE_EXE_LINKER_FLAGS_INIT " -lrtemsdefaultconfig")
>>
>> Also, if you use networking you might want to add.
>>
>> > set(CMAKE_REQUIRED_LIBRARIES "-lbsd")
>>
>> for eg. CheckFunctionExists.cmake to work correctly.
>>
>>
>> The (fairly complex) result of this all can be found here:
>>
>> https://github.com/mdavidsaver/pvxs/tree/master/bundle
>>
>> The essential parts are:
>>
>> - cmake/RTEMS.cmake@
>>
>> Template toolchain file.  (expand using definitions from RTEMS makefiles)
>>
>> - cmake/Platform/
>>
>> Hooks into the CMake startup process.  The exact interplay between
>> Platform/ and toolchain file is... quite involved.  Also not well
>> documented.  The 

Re: [PATCH 04/41] rtems: Add rtems_interrupt_cause_on()

[Gedare Bloom]

Before we bake this into the API forever, I want to ask if "cause" is
the right word to use here? Often, "interrupt cause" is thought of as
a noun to mean what caused the interrupt, while the verb is usually
"raise" or post, trigger, etc. Because "cause" is both a noun and a
verb that mean something in this context, it may be better to use a
different verb. English is pretty much terrible.

I don't have a major problem with sticking to "cause" but thought I'd
bring this up.

On Mon, Jul 12, 2021 at 6:50 AM Sebastian Huber
 wrote:
>
> Document the currently not implemented rtems_interrupt_cause() and
> rtems_interrupt_clear().
>
> Update #3269.
> ---
>  cpukit/include/rtems/rtems/intr.h | 162 +++---
>  1 file changed, 125 insertions(+), 37 deletions(-)
>
> diff --git a/cpukit/include/rtems/rtems/intr.h 
> b/cpukit/include/rtems/rtems/intr.h
> index 178cf342df..a8b1b892b5 100644
> --- a/cpukit/include/rtems/rtems/intr.h
> +++ b/cpukit/include/rtems/rtems/intr.h
> @@ -54,6 +54,7 @@
>  #ifndef _RTEMS_RTEMS_INTR_H
>  #define _RTEMS_RTEMS_INTR_H
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -99,7 +100,7 @@ typedef ISR_Handler rtems_isr;
>   * @ingroup RTEMSAPIClassicIntr
>   *
>   * @brief Interrupt service routines installed by rtems_interrupt_catch() 
> shall
> - *   have this function pointer type.
> + *   have this type.
>   */
>  #if CPU_SIMPLE_VECTORED_INTERRUPTS == TRUE
>typedef ISR_Handler_entry rtems_isr_entry;
> @@ -502,42 +503,6 @@ rtems_status_code rtems_interrupt_catch(
>   */
>  #define rtems_interrupt_is_in_progress() _ISR_Is_in_progress()
>
> -/* Generated from spec:/rtems/intr/if/cause */
> -
> -/**
> - * @ingroup RTEMSAPIClassicIntr
> - *
> - * @brief Causes the interrupt.
> - *
> - * @param _vector is the vector number of the interrupt to cause.
> - *
> - * @par Constraints
> - * @parblock
> - * The following constraints apply to this directive:
> - *
> - * * The directive is not implemented.
> - * @endparblock
> - */
> -#define rtems_interrupt_cause( _vector ) do { } while ( 0 )
> -
> -/* Generated from spec:/rtems/intr/if/clear */
> -
> -/**
> - * @ingroup RTEMSAPIClassicIntr
> - *
> - * @brief Clears the interrupt.
> - *
> - * @param _vector is the vector number of the interrupt to clear.
> - *
> - * @par Constraints
> - * @parblock
> - * The following constraints apply to this directive:
> - *
> - * * The directive is not implemented.
> - * @endparblock
> - */
> -#define rtems_interrupt_clear( _vector ) do { } while ( 0 )
> -
>  /* Generated from spec:/rtems/intr/if/lock-initialize */
>
>  /**
> @@ -909,6 +874,129 @@ rtems_status_code rtems_interrupt_catch(
>  #define RTEMS_INTERRUPT_LOCK_REFERENCE( _designator, _target ) \
>ISR_LOCK_REFERENCE( _designator, _target )
>
> +/* Generated from spec:/rtems/intr/if/cause */
> +
> +/**
> + * @ingroup RTEMSAPIClassicIntr
> + *
> + * @brief Causes the interrupt vector.
> + *
> + * @param vector is the number of the interrupt vector to cause.
> + *
> + * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
> + *
> + * @retval ::RTEMS_INVALID_ID There was no interrupt vector associated with 
> the
> + *   number specified by ``vector``.
> + *
> + * @retval ::RTEMS_UNSATISFIED The request to cause the interrupt vector has
> + *   not been satisfied.
> + *
> + * @par Notes
> + * The rtems_interrupt_get_attributes() directive may be used to check if an
> + * interrupt vector can be caused.
> + *
> + * @par Constraints
> + * @parblock
> + * The following constraints apply to this directive:
> + *
> + * * The directive may be called from within interrupt context.
> + *
> + * * The directive may be called from within device driver initialization
> + *   context.
> + *
> + * * The directive may be called from within task context.
> + *
> + * * The directive will not cause the calling task to be preempted.
> + * @endparblock
> + */
> +rtems_status_code rtems_interrupt_cause( rtems_vector_number vector );
> +
> +/* Generated from spec:/rtems/intr/if/cause-on */
> +
> +/**
> + * @ingroup RTEMSAPIClassicIntr
> + *
> + * @brief Causes the interrupt vector on the processor.
> + *
> + * @param vector is the number of the interrupt vector to cause.
> + *
> + * @param cpu_index is the index of the target processor of the interrupt
> + *   vector to cause.
> + *
> + * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
> + *
> + * @retval ::RTEMS_INVALID_ID There was no interrupt vector associated with 
> the
> + *   number specified by ``vector``.
> + *
> + * @retval ::RTEMS_NOT_CONFIGURED The processor specified by ``cpu_index`` 
> was
> + *   not configured to be used by the application.
> + *
> + * @retval ::RTEMS_INCORRECT_STATE The processor specified by ``cpu_index`` 
> was
> + *   configured to be used by the application, however, it was not online.
> + *
> + * @retval ::RTEMS_UNSATISFIED The request to cause the interrupt vector has
> + *   not been satisfied.
> + *
> + * @par Notes
> 

Re: [PATCH 13/41] bsps/irq: Add rtems_interrupt_get_attributes()

[Gedare Bloom]

On Mon, Jul 12, 2021 at 6:51 AM Sebastian Huber
 wrote:
>
> Add a default implementation which clears the attributes to zero and
> just returns RTEMS_SUCCESSFUL for valid parameters.
>
> Update #3269.
> ---
>  bsps/arm/beagle/irq/irq.c |  8 ++
>  bsps/arm/csb336/irq/irq.c |  8 ++
>  bsps/arm/csb337/irq/irq.c |  8 ++
>  bsps/arm/edb7312/irq/irq.c|  8 ++
>  bsps/arm/gumstix/irq/irq.c|  8 ++
>  bsps/arm/lpc24xx/irq/irq.c|  8 ++
>  bsps/arm/lpc32xx/irq/irq.c|  8 ++
>  bsps/arm/raspberrypi/irq/irq.c|  8 ++
>  bsps/arm/rtl22xx/irq/irq.c|  8 ++
>  bsps/arm/shared/irq/irq-armv7m.c  |  8 ++
>  bsps/arm/smdk2410/irq/irq.c   |  8 ++
>  bsps/arm/tms570/irq/irq.c |  8 ++
>  bsps/i386/shared/irq/irq.c|  8 ++
>  bsps/include/bsp/irq-generic.h| 17 
>  bsps/lm32/shared/irq/irq.c|  8 ++
>  bsps/m68k/genmcf548x/irq/irq.c|  8 ++
>  bsps/mips/shared/irq/irq.c|  8 ++
>  bsps/powerpc/gen5200/irq/irq.c|  8 ++
>  bsps/powerpc/gen83xx/irq/irq.c|  8 ++
>  bsps/powerpc/mpc55xxevb/start/irq.c   |  8 ++
>  bsps/powerpc/mpc8260ads/irq/irq.c |  8 ++
>  bsps/powerpc/psim/irq/irq_init.c  |  8 ++
>  bsps/powerpc/qemuppc/irq/irq_init.c   |  8 ++
>  bsps/powerpc/qoriq/irq/irq.c  | 16 +++
>  bsps/powerpc/shared/irq/ppc-irq-generic.c |  8 ++
>  bsps/powerpc/t32mppc/irq/irq.c|  8 ++
>  bsps/powerpc/tqm8xx/irq/irq.c |  8 ++
>  bsps/powerpc/virtex/irq/irq_init.c|  8 ++
>  bsps/riscv/griscv/irq/irq.c   |  8 ++
>  bsps/riscv/riscv/irq/irq.c|  8 ++
>  bsps/shared/dev/irq/arm-gicv2.c   |  8 ++
>  bsps/shared/dev/irq/arm-gicv3.c   |  8 ++
>  bsps/shared/irq/irq-default.c |  8 ++
>  bsps/shared/irq/irq-enable-disable.c  | 33 +--
>  bsps/sparc/leon3/start/eirq.c |  8 ++
>  bsps/sparc/shared/irq/irq-shared.c|  8 ++
>  bsps/x86_64/amd64/interrupts/idt.c|  9 +++
>  37 files changed, 337 insertions(+), 2 deletions(-)
>
> diff --git a/bsps/arm/beagle/irq/irq.c b/bsps/arm/beagle/irq/irq.c
> index 9ba317f64f..d54b49f0ca 100644
> --- a/bsps/arm/beagle/irq/irq.c
> +++ b/bsps/arm/beagle/irq/irq.c
> @@ -95,6 +95,14 @@ static uint32_t omap_get_mir_reg(rtems_vector_number 
> vector, uint32_t *const mas
>return mir_reg;
>  }
>
> +rtems_status_code bsp_interrupt_get_attributes(
> +  rtems_vector_number vector,
> +  rtems_interrupt_attributes *attributes
> +)
> +{
> +  return RTEMS_SUCCESSFUL;
> +}
> +
>  rtems_status_code bsp_interrupt_cause(rtems_vector_number vector)
>  {
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
> diff --git a/bsps/arm/csb336/irq/irq.c b/bsps/arm/csb336/irq/irq.c
> index 4c24c4c09d..2cc4f5bb5c 100644
> --- a/bsps/arm/csb336/irq/irq.c
> +++ b/bsps/arm/csb336/irq/irq.c
> @@ -26,6 +26,14 @@ void bsp_interrupt_dispatch(void)
>bsp_interrupt_handler_dispatch(vector);
>  }
>
> +rtems_status_code bsp_interrupt_get_attributes(
> +  rtems_vector_number vector,
> +  rtems_interrupt_attributes *attributes
> +)
> +{
> +  return RTEMS_SUCCESSFUL;
> +}
> +
>  rtems_status_code bsp_interrupt_cause(rtems_vector_number vector)
>  {
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
> diff --git a/bsps/arm/csb337/irq/irq.c b/bsps/arm/csb337/irq/irq.c
> index 730b680b6a..1679b89dc3 100644
> --- a/bsps/arm/csb337/irq/irq.c
> +++ b/bsps/arm/csb337/irq/irq.c
> @@ -27,6 +27,14 @@ void bsp_interrupt_dispatch(void)
>AIC_CTL_REG(AIC_EOICR) = 0;
>  }
>
> +rtems_status_code bsp_interrupt_get_attributes(
> +  rtems_vector_number vector,
> +  rtems_interrupt_attributes *attributes
> +)
> +{
> +  return RTEMS_SUCCESSFUL;
> +}
> +
>  rtems_status_code bsp_interrupt_cause(rtems_vector_number vector)
>  {
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
> diff --git a/bsps/arm/edb7312/irq/irq.c b/bsps/arm/edb7312/irq/irq.c
> index 6096bf7023..573e4f015d 100644
> --- a/bsps/arm/edb7312/irq/irq.c
> +++ b/bsps/arm/edb7312/irq/irq.c
> @@ -27,6 +27,14 @@ void edb7312_interrupt_dispatch(rtems_vector_number vector)
>bsp_interrupt_handler_dispatch(vector);
>  }
>
> +rtems_status_code bsp_interrupt_get_attributes(
> +  rtems_vector_number vector,
> +  rtems_interrupt_attributes *attributes
> +)
> +{
> +  return RTEMS_SUCCESSFUL;
> +}
> +
>  rtems_status_code bsp_interrupt_cause(rtems_vector_number vector)
>  {
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
> diff --git a/bsps/arm/gumstix/irq/irq.c b/bsps/arm/gumstix/irq/irq.c
> index dc69274df3..9a185e247b 100644
> --- 

Re: [PATCH 06/41] rtems: Add rtems_interrupt_get_attributes()

[Gedare Bloom]

On Wed, Jul 21, 2021 at 12:07 PM Sebastian Huber
 wrote:
>
> On 21/07/2021 20:00, Gedare Bloom wrote:
> >> +  /**
> >> +   * @brief This member is true, if the interrupt vector may be enabled by
> >> +   *   rtems_interrupt_vector_enable(), otherwise it is false.
> >> +   *
> >> +   * When an interrupt vector may be enabled, this means that the enabled 
> >> state
> >> +   * may be changed from disabled to enabled and from enabled to enabled. 
> >>  The
> > s/may/might
> > It is more proper to say "might" when something "might not". "may" and
> > "can" are close synonyms, but "maybe" is closer to "might" in usage.
> > English is still terrible.
> >
>
> For the tests we need two variants. One (currently "can") for which it
> is certain that the operation is successful. Another one (currently
> "maybe") for which the the operation could be successful or unsatisfied.
>
> For the "may_be_triggered_by_message" I would like to express that
> messages can trigger the interrupt, however, there may be also other
> triggers like signals or software.
>
Ok, i think this use of "may" actually does cover the difference. It's
just subtle. I'm fine with it here.

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 05/41] rtems: Generate

[Gedare Bloom]

On Wed, Jul 21, 2021 at 11:59 AM Sebastian Huber
 wrote:
>
> On 21/07/2021 19:50, Gedare Bloom wrote:
> >>   /*
> >> - * Based on concepts of Pavel Pisa, Till Straumann and Eric Valette.
> > We lose some kind of historical record / attribution here. I wonder
> > if, based on the other discussion about sponsor attribution, there
> > should be something in the generated header for any non-copyright
> > attribution (e.g., if someone wants their authorship reflected)?
> >
> > I don't think it matters so much. Those three guys have their
> > contributions well-reflected in other parts of RTEMS.
> >
>
> The concept of the interrupt manager extension API is based on a mailing
> list discussion. From my point of view there is no copyrightable content
> from these three persons in the header file. With respect to the
> attribution, I would be in favour of a general RTEMS contributors file.
> We already have something like this in "c/ACKNOWLEDGEMENTS", but it is
> not up to date.
>
ok, thanks that's fine with me. I'm still slogging through the
remainder of this patch set.

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 21/41] rtems: Add rtems_interrupt_entry_install()

[Gedare Bloom]

On Mon, Jul 12, 2021 at 6:51 AM Sebastian Huber
 wrote:
>
> Add RTEMS_INTERRUPT_ENTRY_INITIALIZER(),
> rtems_interrupt_entry_initialize(), and
> rtems_interrupt_entry_remove().  This allows to install interrupt
> handlers using user-provides storage as an alternative to

nit: user-provided

> rtems_interrupt_handler_install() which has to allocate memory.
>
> Update #3269.
> ---
>  cpukit/include/rtems/irq-extension.h | 237 +++
>  1 file changed, 237 insertions(+)
>
> diff --git a/cpukit/include/rtems/irq-extension.h 
> b/cpukit/include/rtems/irq-extension.h
> index c96dfd7d5c..c012a26452 100644
> --- a/cpukit/include/rtems/irq-extension.h
> +++ b/cpukit/include/rtems/irq-extension.h
> @@ -166,6 +166,243 @@ typedef void ( *rtems_interrupt_per_handler_routine )(
>  #define RTEMS_INTERRUPT_IS_REPLACE( _options ) \
>( ( _options ) & RTEMS_INTERRUPT_REPLACE )
>
> +/* Generated from spec:/rtems/intr/if/entry */
> +
> +/**
> + * @ingroup RTEMSAPIClassicIntr
> + *
> + * @brief This structure represents an interrupt entry.
> + *
> + * @par Notes
> + * This structure shall be treated as an opaque data type from the API point 
> of
> + * view.  Members shall not be accessed directly.  An entry may be 
> initialized
> + * by RTEMS_INTERRUPT_ENTRY_INITIALIZER() or
> + * rtems_interrupt_entry_initialize().  It may be installed for an interrupt
> + * vector with rtems_interrupt_entry_install() and removed from an interrupt
> + * vector by rtems_interrupt_entry_remove().
> + */
> +typedef struct rtems_interrupt_entry {
> +  /**
> +   * @brief This member is the interrupt handler routine.
> +   */
> +  rtems_interrupt_handler handler;
> +
> +  /**
> +   * @brief This member is the interrupt handler argument.
> +   */
> +  void *arg;
> +
> +  /**
> +   * @brief This member is the reference to the next entry or NULL.
> +   */
> +  struct rtems_interrupt_entry *next;
> +
> +  /**
> +   * @brief This member is the descriptive information of the entry
nit: missing period

> +   */
> +  const char *info;
> +} rtems_interrupt_entry;
> +
> +/* Generated from spec:/rtems/intr/if/entry-initializer */
> +
> +/**
> + * @ingroup RTEMSAPIClassicIntr
> + *
> + * @brief Statically initializes an interrupt entry object.
> + *
> + * @param _routine is the interrupt handler routine for the entry.
> + *
> + * @param _arg is the interrupt handler argument for the entry.
> + *
> + * @param _info is the descriptive information for the entry.
> + *
> + * @par Notes
> + * Alternatively, rtems_interrupt_entry_initialize() may be used to 
> dynamically
> + * initialize an interrupt entry.
> + */
> +#define RTEMS_INTERRUPT_ENTRY_INITIALIZER( _routine, _arg, _info ) \
> +  { _routine,  _arg, NULL, _info }
> +
> +/* Generated from spec:/rtems/intr/if/entry-initialize */
> +
> +/**
> + * @ingroup RTEMSAPIClassicIntr
> + *
> + * @brief Initializes the interrupt entry.
> + *
> + * @param[out] entry is the interrupt entry to initialize.
> + *
> + * @param routine is the interrupt handler routine for the entry.
> + *
> + * @param arg is the interrupt handler argument for the entry.
> + *
> + * @param info is the descriptive information for the entry.
> + *
> + * @par Notes
> + * Alternatively, RTEMS_INTERRUPT_ENTRY_INITIALIZER() may be used to 
> statically
> + * initialize an interrupt entry.
> + *
> + * @par Constraints
> + * @parblock
> + * The following constraints apply to this directive:
> + *
> + * * The directive may be called from within any runtime context.
> + *
> + * * The directive will not cause the calling task to be preempted.
> + * @endparblock
> + */
> +static inline void rtems_interrupt_entry_initialize(
> +  rtems_interrupt_entry  *entry,
> +  rtems_interrupt_handler routine,
> +  void   *arg,
> +  const char *info
> +)
> +{
> +  entry->handler = routine;
> +  entry->arg = arg;
> +  entry->next = NULL;
> +  entry->info = info;
> +}
> +
> +/* Generated from spec:/rtems/intr/if/entry-install */
> +
> +/**
> + * @ingroup RTEMSAPIClassicIntr
> + *
> + * @brief Installs the interrupt entry at the interrupt vector.
> + *
> + * @param vector is the interrupt vector number.
> + *
> + * @param options is the interrupt entry install option set.
> + *
> + * @param entry is the interrupt entry to install
missing period

> + *
> + * One of the following mutually exclusive options
> + *
> + * * #RTEMS_INTERRUPT_UNIQUE, and
> + *
> + * * #RTEMS_INTERRUPT_SHARED
> + *
> + * shall be set in the ``options`` parameter.
> + *
> + * The handler routine of the entry specified by ``entry`` will be called 
> with
> + * the handler argument of the entry when dispatched.  The order in which
> + * shared interrupt handlers are dispatched for one vector is defined by the
> + * installation order.  The first installed handler is dispatched first.
> + *
> + * If the option #RTEMS_INTERRUPT_UNIQUE is set, then it will be ensured that
> + * the handler will be the only one for the interrupt vector.
> + *
> + * 

Re: [PATCH 06/41] rtems: Add rtems_interrupt_get_attributes()

[Gedare Bloom]

On Mon, Jul 12, 2021 at 6:50 AM Sebastian Huber
 wrote:
>
> Add a directive to query the attributes of an interrupt vector.   This
nit, add "can"

> be used for generic tests and system diagnostics.
>
> Update #3269.
> ---
>  cpukit/include/rtems/irq-extension.h | 198 +++
>  1 file changed, 198 insertions(+)
>
> diff --git a/cpukit/include/rtems/irq-extension.h 
> b/cpukit/include/rtems/irq-extension.h
> index 5f24fb502e..d6b5cd5e45 100644
> --- a/cpukit/include/rtems/irq-extension.h
> +++ b/cpukit/include/rtems/irq-extension.h
> @@ -419,6 +419,204 @@ rtems_status_code rtems_interrupt_set_affinity(
>const cpu_set_t*affinity
>  );
>
> +/* Generated from spec:/rtems/intr/if/signal-variant */
> +
> +/**
> + * @ingroup RTEMSAPIClassicIntr
> + *
> + * @brief This enumeration provides interrupt trigger signal variants.
> + */
> +typedef enum {
> +  /**
> +   * @brief This interrupt signal variant indicates that the interrupt 
> trigger
> +   *   signal is unspecified.
> +   */
> +  RTEMS_INTERRUPT_SIGNAL_UNSPECIFIED,
> +
> +  /**
> +   * @brief This interrupt signal variant indicates that the interrupt is
> +   *   triggered by a low level signal.
> +   */
> +  RTEMS_INTERRUPT_SIGNAL_LEVEL_LOW,
> +
> +  /**
> +   * @brief This interrupt signal variant indicates that the interrupt is
> +   *   triggered by a high level signal.
> +   */
> +  RTEMS_INTERRUPT_SIGNAL_LEVEL_HIGH,
> +
> +  /**
> +   * @brief This interrupt signal variant indicates that the interrupt is
> +   *   triggered by a falling edge signal.
> +   */
> +  RTEMS_INTERRUPT_SIGNAL_EDGE_FALLING,
> +
> +  /**
> +   * @brief This interrupt signal variant indicates that the interrupt is
> +   *   triggered by a raising edge signal.
> +   */
> +  RTEMS_INTERRUPT_SIGNAL_EDGE_RAISING
> +} rtems_interrupt_signal_variant;
> +
> +/* Generated from spec:/rtems/intr/if/attributes */
> +
> +/**
> + * @ingroup RTEMSAPIClassicIntr
> + *
> + * @brief This structure provides the attributes of an interrupt vector.
> + *
> + * The rtems_interrupt_get_attributes() directive may be used to obtain the
> + * attributes of an interrupt vector.
> + */
> +typedef struct {
> +  /**
> +   * @brief This member is true, if the interrupt vector is maskable by
> +   *   rtems_interrupt_local_disable(), otherwise it is false.
> +   *
> +   * Interrupt vectors which are not maskable by 
> rtems_interrupt_local_disable()
> +   * should be used with care since they cannot use most operating system
> +   * services.
> +   */
> +  bool is_maskable;
> +
> +  /**
> +   * @brief This member is true, if the interrupt vector is always enabled,
> +   *   otherwise it is false.
> +   *
> +   * For an always enabled interrupt vector it follows that it can be 
> enabled and
> +   * that it cannot be disabled.
Should this refer to the attributes explicitly? (can_enable == true
and can_disable == false)

> +   */
> +  bool always_enabled;
> +
> +  /**
> +   * @brief This member is true, if the interrupt vector can be enabled by
> +   *   rtems_interrupt_vector_enable(), otherwise it is false.
> +   *
> +   * When an interrupt vector can be enabled, this means that the enabled 
> state
> +   * can always be changed from disabled to enabled and from enabled to 
> enabled.
> +   * For an interrupt vector which can be enabled it follows that it may be
> +   * enabled.
> +   */
> +  bool can_enable;
> +
> +  /**
> +   * @brief This member is true, if the interrupt vector may be enabled by
> +   *   rtems_interrupt_vector_enable(), otherwise it is false.
> +   *
> +   * When an interrupt vector may be enabled, this means that the enabled 
> state
> +   * may be changed from disabled to enabled and from enabled to enabled.  
> The
s/may/might
It is more proper to say "might" when something "might not". "may" and
"can" are close synonyms, but "maybe" is closer to "might" in usage.
English is still terrible.

> +   * requested enabled state change should be checked by
> +   * rtems_interrupt_vector_is_enabled().  Some interrupt vectors may be
> +   * optionally avaialable and cannot be enabled on a particular target.
available

> +   */
> +  bool maybe_enable;
> +
> +  /**
> +   * @brief This member is true, if the interrupt vector can be disabled by
> +   *   rtems_interrupt_vector_disable(), otherwise it is false.
> +   *
> +   * When an interrupt vector can be disabled, this means that the enabled 
> state
> +   * can be changed from disabled to disabled and from enabled to disabled.
> +   */
> +  bool can_disable;
> +
> +  /**
> +   * @brief This member is true, if the interrupt vector can be caused by
> +   *   rtems_interrupt_cause(), otherwise it is false.
> +   */
> +  bool can_cause;
> +
> +  /**
> +   * @brief This member is true, if the interrupt vector can be caused on a
> +   *   processor by rtems_interrupt_cause_on(), otherwise it is false.
> +   */
> +  bool can_cause_on;
> +
> +  /**
> +   * @brief This member is true, if the interrupt vector can be cleared 

Re: [PATCH 09/41] rtems: Add rtems_interrupt_is_pending()

[Gedare Bloom]

On Mon, Jul 12, 2021 at 6:51 AM Sebastian Huber
 wrote:
>
> Update #3269.
> ---
>  cpukit/include/rtems/irq-extension.h | 54 
>  1 file changed, 54 insertions(+)
>
> diff --git a/cpukit/include/rtems/irq-extension.h 
> b/cpukit/include/rtems/irq-extension.h
> index 4a8f0b7879..c96dfd7d5c 100644
> --- a/cpukit/include/rtems/irq-extension.h
> +++ b/cpukit/include/rtems/irq-extension.h
> @@ -453,6 +453,60 @@ rtems_status_code rtems_interrupt_vector_enable( 
> rtems_vector_number vector );
>   */
>  rtems_status_code rtems_interrupt_vector_disable( rtems_vector_number vector 
> );
>
> +/* Generated from spec:/rtems/intr/if/is-pending */
> +
> +/**
> + * @ingroup RTEMSAPIClassicIntr
> + *
> + * @brief Checks if the interrupt is pending.
> + *
> + * @param vector is the interrupt vector number.
> + *
> + * @param[out] pending is the pointer to a ``bool`` object.  When the 
> directive
> + *   call is successful, the pending status of the interrupt associated with
> + *   the interrupt vector specified by ``vector`` will be stored in this
> + *   object.  When the interrupt was pending for the processor executing the
> + *   directive call at some time point during the call, the object value will
> + *   be set to true, otherwise to false.
> + *
> + * The directive checks if the interrupt associated with the interrupt vector
> + * specified by ``vector`` was pending for the processor executing the
> + * directive call at some time point during the call.
> + *
> + * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
> + *
> + * @retval ::RTEMS_INVALID_ADDRESS The ``pending`` parameter was NULL.
> + *
> + * @retval ::RTEMS_INVALID_ID There was no interrupt vector associated with 
> the
> + *   number specified by ``vector``.
> + *
> + * @retval ::RTEMS_UNSATISFIED The request to get the pending status has not
> + *   been satisfied.
> + *
> + * @par Notes
> + * Interrupts may be made pending by calling the rtems_interrupt_cause() or
> + * rtems_interrupt_cause_on() directives or due to exernal signals or 
> messages.
external

> + * The pending state may be cleared by rtems_interrupt_clear().
> + *
> + * @par Constraints
> + * @parblock
> + * The following constraints apply to this directive:
> + *
> + * * The directive may be called from within interrupt context.
> + *
> + * * The directive may be called from within device driver initialization
> + *   context.
> + *
> + * * The directive may be called from within task context.
> + *
> + * * The directive will not cause the calling task to be preempted.
> + * @endparblock
> + */
> +rtems_status_code rtems_interrupt_is_pending(
> +  rtems_vector_number vector,
> +  bool   *pending
> +);
> +
>  /* Generated from spec:/rtems/intr/if/get-affinity */
>
>  /**
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 19/41] bsps/irq: Implement new directives for GICv2/3

[Sebastian Huber]

On 21/07/2021 20:25, Gedare Bloom wrote:

As far as I'm aware, SGIs can be enabled or disabled using GICD_ISENABLER0
just like

PPI or SPI interrupts for both GICv2 and GICv3. Section 3.1.2 of the GICv2
architecture

spec (IHI0048B) references this, though I have seen implementations where
certain SGI

and PPI interrupts are hard-wired enabled or disabled and that state can't be
changed

(which is also covered in this section).

Ok, on Qemu and the i.MX7D the SGI are always enabled. I would keep the
attributes like this until we have a system which is different.

Should a comment be added that says this?


Yes, in case someone else comes along to add support for a system that
is different, it will help to give them some pointers.


I addressed this with new attributes in the v2 patch versions:

https://lists.rtems.org/pipermail/devel/2021-July/068276.html


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 20/41] sparc/irq: Implement new interrupt directives

[Gedare Bloom]

On Mon, Jul 12, 2021 at 6:50 AM Sebastian Huber
 wrote:
>
> Update #3269.
> ---
>  bsps/sparc/leon3/start/eirq.c  | 86 +++---
>  bsps/sparc/shared/irq/irq-shared.c | 17 --
>  2 files changed, 91 insertions(+), 12 deletions(-)
>
> diff --git a/bsps/sparc/leon3/start/eirq.c b/bsps/sparc/leon3/start/eirq.c
> index d6373bf00a..4f5f910106 100644
> --- a/bsps/sparc/leon3/start/eirq.c
> +++ b/bsps/sparc/leon3/start/eirq.c
> @@ -66,6 +66,19 @@ rtems_status_code bsp_interrupt_get_attributes(
>rtems_interrupt_attributes *attributes
>  )
>  {
> +  bool is_standard_interrupt;
> +
> +  is_standard_interrupt = (vector <= BSP_INTERRUPT_VECTOR_MAX_STD);
> +  attributes->is_maskable = (vector != 15);
> +  attributes->can_enable = true;
> +  attributes->maybe_enable = true;
> +  attributes->can_disable = true;
> +  attributes->can_cause = true;
> +  attributes->can_cause_on = is_standard_interrupt;
> +  attributes->can_clear = true;
> +  attributes->cleared_by_acknowledge = true;
> +  attributes->can_get_affinity = is_standard_interrupt;
> +  attributes->can_set_affinity = is_standard_interrupt;
>return RTEMS_SUCCESSFUL;
>  }
>
> @@ -74,16 +87,56 @@ rtems_status_code bsp_interrupt_is_pending(
>bool   *pending
>  )
>  {
> +#if defined(RTEMS_SMP)
> +  rtems_interrupt_level level;
> +  uint32_t bit;
> +
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
>bsp_interrupt_assert(pending != NULL);
> -  *pending = false;
> -  return RTEMS_UNSATISFIED;
> +  bit = 1U << vector;
> +
> +  rtems_interrupt_local_disable(level);
> +  *pending = (LEON3_IrqCtrl_Regs->ipend & bit) != 0 ||
> +(LEON3_IrqCtrl_Regs->force[rtems_scheduler_get_processor()] & bit) != 0;
> +  rtems_interrupt_local_enable(level);
> +  return RTEMS_SUCCESSFUL;
> +#else
> +  bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
> +  *pending = !BSP_Is_interrupt_pending(vector);
> +  return RTEMS_SUCCESSFUL;
> +#endif
>  }
>
>  rtems_status_code bsp_interrupt_cause(rtems_vector_number vector)
>  {
> +  uint32_t bit;
> +
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
> -  return RTEMS_UNSATISFIED;
> +  bit = 1U << vector;
> +
> +  if ( vector <= BSP_INTERRUPT_VECTOR_MAX_STD ) {
> +uint32_t cpu_count;
> +uint32_t cpu_index;
> +
> +cpu_count = rtems_scheduler_get_processor_maximum();
> +
> +for (cpu_index = 0; cpu_index < cpu_count; ++cpu_index) {
> +  LEON3_IrqCtrl_Regs->force[cpu_index] = bit;
> +}
> +  } else {

Why not throw an error here instead? In production, you wouldn't want
this code...

> +rtems_interrupt_lock_context lock_context;
> +
> +/*
> + * This is a very dangerous operation and should only be used for test
> + * software.  We may accidentally clear the pending state set by
> + * peripherals with this read-modify-write operation.
> + */
> +LEON3_IRQCTRL_ACQUIRE(_context);
> +LEON3_IrqCtrl_Regs->ipend |= bit;
> +LEON3_IRQCTRL_RELEASE(_context);
> +  }
> +
> +  return RTEMS_SUCCESSFUL;
>  }
>
>  #if defined(RTEMS_SMP)
> @@ -93,14 +146,31 @@ rtems_status_code bsp_interrupt_cause_on(
>  )
>  {
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
> -  return RTEMS_UNSATISFIED;
> +  bsp_interrupt_assert(cpu_index < rtems_scheduler_get_processor_maximum());
> +
> +  if ( vector > BSP_INTERRUPT_VECTOR_MAX_STD ) {
> +return RTEMS_UNSATISFIED;
> +  }
> +
> +  LEON3_IrqCtrl_Regs->force[cpu_index] = 1U << vector;
> +  return RTEMS_SUCCESSFUL;
>  }
>  #endif
>
>  rtems_status_code bsp_interrupt_clear(rtems_vector_number vector)
>  {
> +  uint32_t bit;
> +
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
> -  return RTEMS_UNSATISFIED;
> +  bit = 1U << vector;
> +
> +  LEON3_IrqCtrl_Regs->iclear = bit;
> +
> +  if (vector <= BSP_INTERRUPT_VECTOR_MAX_STD) {
> +LEON3_IrqCtrl_Regs->force[rtems_scheduler_get_processor()] = bit << 16;
> +  }
> +
> +  return RTEMS_SUCCESSFUL;
>  }
>
>  rtems_status_code bsp_interrupt_vector_is_enabled(
> @@ -109,9 +179,9 @@ rtems_status_code bsp_interrupt_vector_is_enabled(
>  )
>  {
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
> -  bsp_interrupt_assert(enabled != NULL);
> -  *enabled = false;
> -  return RTEMS_UNSATISFIED;
> +  *enabled =
> +!BSP_Cpu_Is_interrupt_masked(vector, _LEON3_Get_current_processor());
> +  return RTEMS_SUCCESSFUL;
>  }
>
>  #if defined(RTEMS_SMP)
> diff --git a/bsps/sparc/shared/irq/irq-shared.c 
> b/bsps/sparc/shared/irq/irq-shared.c
> index aa1d412be0..d0b77bddbb 100644
> --- a/bsps/sparc/shared/irq/irq-shared.c
> +++ b/bsps/sparc/shared/irq/irq-shared.c
> @@ -37,6 +37,13 @@ rtems_status_code bsp_interrupt_get_attributes(
>rtems_interrupt_attributes *attributes
>  )
>  {
> +  attributes->is_maskable = vector != 15;
> +  attributes->can_enable = true;
> +  attributes->can_disable = true;
> +  attributes->can_cause = true;
> +  attributes->can_cause_on = true;
> +  attributes->can_clear = 

Re: [PATCH 25/41] bsps/irq: Add rtems_interrupt_entry_install()

[Gedare Bloom]

On Mon, Jul 12, 2021 at 6:51 AM Sebastian Huber
 wrote:
>
> Add rtems_interrupt_entry_remove().  Split up irq-generic.c into several 
> files.
> In particular, place all functions which use dynamic memory into their own
> file.
>
> Add optional macros to let the BSP customize the vector installation after
> installing the first entry and the vector removal before removing the last
> entry:
>
> * bsp_interrupt_vector_install()
>
> * bsp_interrupt_vector_remove()
>
> Use these new customization options in the m68k/genmcf548x BSP so re-use the
> generic interrupt controller support.
>
> Update #3269.
> ---
>  bsps/i386/shared/irq/irq.c   |   8 +-
>  bsps/include/bsp/irq-generic.h   | 214 ++--
>  bsps/m68k/genmcf548x/include/bsp/irq.h   |   8 +
>  bsps/m68k/genmcf548x/irq/irq.c   | 140 +-
>  bsps/shared/irq-default-sources.am   |   3 +
>  bsps/shared/irq-sources.am   |   3 +
>  bsps/shared/irq/irq-entry-remove.c   | 115 +
>  bsps/shared/irq/irq-generic.c| 486 ++-
>  bsps/shared/irq/irq-handler-install.c| 114 +
>  bsps/shared/irq/irq-handler-iterate.c|  21 +-
>  bsps/shared/irq/irq-handler-remove.c |  80 +++
>  c/src/lib/libbsp/m68k/genmcf548x/Makefile.am |  10 +-
>  c/src/lib/libbsp/powerpc/ss555/Makefile.am   |   3 +
>  spec/build/bsps/m68k/genmcf548x/grp.yml  |   2 +
>  spec/build/bsps/m68k/genmcf548x/obj.yml  |   9 -
>  spec/build/bsps/objirq.yml   |   3 +
>  spec/build/bsps/powerpc/ss555/bspss555.yml   |   3 +
>  17 files changed, 681 insertions(+), 541 deletions(-)
>  create mode 100644 bsps/shared/irq/irq-entry-remove.c
>  create mode 100644 bsps/shared/irq/irq-handler-install.c
>  create mode 100644 bsps/shared/irq/irq-handler-remove.c
>
> diff --git a/bsps/i386/shared/irq/irq.c b/bsps/i386/shared/irq/irq.c
> index d0004698e7..25f8fb69b0 100644
> --- a/bsps/i386/shared/irq/irq.c
> +++ b/bsps/i386/shared/irq/irq.c
> @@ -353,13 +353,7 @@ rtems_status_code bsp_interrupt_facility_initialize(void)
>
>  static bool bsp_interrupt_handler_is_empty(rtems_vector_number vector)
>  {
> -  rtems_vector_number index;
> -  rtems_interrupt_entry *head;
> -
> -  index = bsp_interrupt_handler_index(vector);
> -  head = _interrupt_handler_table[index];
> -
> -  return bsp_interrupt_is_empty_handler_entry(head);
> +  return bsp_interrupt_entry_load_first(vector) == NULL;
>  }
>
>  /*
> diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h
> index 3b2998f533..6e2f5ed464 100644
> --- a/bsps/include/bsp/irq-generic.h
> +++ b/bsps/include/bsp/irq-generic.h
> @@ -12,7 +12,7 @@
>  /*
>   * Copyright (C) 2016 Chris Johns 
>   *
> - * Copyright (C) 2008, 2017 embedded brains GmbH 
> (http://www.embedded-brains.de)
> + * Copyright (C) 2008, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
>   *
>   * Redistribution and use in source and binary forms, with or without
>   * modification, are permitted provided that the following conditions
> @@ -70,20 +70,13 @@ extern "C" {
>#define BSP_INTERRUPT_HANDLER_TABLE_SIZE BSP_INTERRUPT_VECTOR_COUNT
>  #endif
>
> -/* Internal macros for SMP support, do not use externally */
> -#ifdef RTEMS_SMP
> -  #define bsp_interrupt_disable(level) do { (void) level; } while (0)
> -  #define bsp_interrupt_enable(level) do { } while (0)
> -  #define bsp_interrupt_fence(order) _Atomic_Fence(order)
> -#else
> -  #define bsp_interrupt_disable(level) rtems_interrupt_disable(level)
> -  #define bsp_interrupt_enable(level) rtems_interrupt_enable(level)
> -  #define bsp_interrupt_fence(order) do { } while (0)
> -#endif
> -
>  #define bsp_interrupt_assert(e) _Assert(e)
>
> -extern rtems_interrupt_entry bsp_interrupt_handler_table [];
> +/**
> + * @brief Each member of this table references the first installed entry at 
> the
> + *   corresponding interrupt vector or is NULL.
> + */
> +extern rtems_interrupt_entry *bsp_interrupt_handler_table[];
>
>  #ifdef BSP_INTERRUPT_USE_INDEX_TABLE
>#if BSP_INTERRUPT_HANDLER_TABLE_SIZE < 0x100
> @@ -141,6 +134,12 @@ static inline rtems_vector_number 
> bsp_interrupt_handler_index(
>   * - bsp_interrupt_vector_disable()
>   * - bsp_interrupt_handler_default()
>   *
> + * Optionally, the BSP may define the following macros to customize the 
> vector
> + * installation after installing the first entry and the vector removal 
> before
> + * removing the last entry:
> + * - bsp_interrupt_vector_install()
> + * - bsp_interrupt_vector_remove()
> + *
>   * The following now deprecated functions are provided for backward
>   * compatibility:
>   * - BSP_get_current_rtems_irq_handler()
> @@ -362,14 +361,114 @@ rtems_status_code bsp_interrupt_cause_on(
>   */
>  rtems_status_code bsp_interrupt_clear( rtems_vector_number vector );
>
> +#if defined(RTEMS_SMP)
> +/**
> + * @brief Handles a spurious interrupt.
> + *
> + * @param vector is the vector number.
> + */
> +void 

Re: [PATCH] build: Add the BSP family to the enable set

[Sebastian Huber]

On 21/07/2021 21:05, Gedare Bloom wrote:

The problem is that one BSP which supports SMP "riscv/griscv" is identical to
the family "riscv/griscv" which contains BSPs which do not support SMP
("riscv/grv32i" and riscv/grv32im").

Hmm, tricky. Can the BSPs that do not support SMP disable SMP in the BSP
specific config, ie override/specialise in the BSP?


Or, can we avoid having duplication between BSP names and family names?


Yes, good idea. We could use a "family/" prefix for example 
("family//").


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 04/41] rtems: Add rtems_interrupt_cause_on()

[Gedare Bloom]

On Wed, Jul 21, 2021 at 11:43 AM Gedare Bloom  wrote:
>
> Before we bake this into the API forever, I want to ask if "cause" is
> the right word to use here? Often, "interrupt cause" is thought of as
> a noun to mean what caused the interrupt, while the verb is usually
> "raise" or post, trigger, etc. Because "cause" is both a noun and a
> verb that mean something in this context, it may be better to use a
> different verb. English is pretty much terrible.
>
> I don't have a major problem with sticking to "cause" but thought I'd
> bring this up.
>
> On Mon, Jul 12, 2021 at 6:50 AM Sebastian Huber
>  wrote:
> >
> > Document the currently not implemented rtems_interrupt_cause() and
> > rtems_interrupt_clear().
> >
> > Update #3269.
> > ---
> >  cpukit/include/rtems/rtems/intr.h | 162 +++---
> >  1 file changed, 125 insertions(+), 37 deletions(-)
> >
> > diff --git a/cpukit/include/rtems/rtems/intr.h 
> > b/cpukit/include/rtems/rtems/intr.h
> > index 178cf342df..a8b1b892b5 100644
> > --- a/cpukit/include/rtems/rtems/intr.h
> > +++ b/cpukit/include/rtems/rtems/intr.h
> > @@ -54,6 +54,7 @@
> >  #ifndef _RTEMS_RTEMS_INTR_H
> >  #define _RTEMS_RTEMS_INTR_H
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -99,7 +100,7 @@ typedef ISR_Handler rtems_isr;
> >   * @ingroup RTEMSAPIClassicIntr
> >   *
> >   * @brief Interrupt service routines installed by rtems_interrupt_catch() 
> > shall
> > - *   have this function pointer type.
> > + *   have this type.
> >   */
> >  #if CPU_SIMPLE_VECTORED_INTERRUPTS == TRUE
> >typedef ISR_Handler_entry rtems_isr_entry;
> > @@ -502,42 +503,6 @@ rtems_status_code rtems_interrupt_catch(
> >   */
> >  #define rtems_interrupt_is_in_progress() _ISR_Is_in_progress()
> >
> > -/* Generated from spec:/rtems/intr/if/cause */
> > -
> > -/**
> > - * @ingroup RTEMSAPIClassicIntr
> > - *
> > - * @brief Causes the interrupt.
> > - *
> > - * @param _vector is the vector number of the interrupt to cause.
> > - *
> > - * @par Constraints
> > - * @parblock
> > - * The following constraints apply to this directive:
> > - *
> > - * * The directive is not implemented.
> > - * @endparblock
> > - */
> > -#define rtems_interrupt_cause( _vector ) do { } while ( 0 )
> > -
> > -/* Generated from spec:/rtems/intr/if/clear */
> > -
> > -/**
> > - * @ingroup RTEMSAPIClassicIntr
> > - *
> > - * @brief Clears the interrupt.
> > - *
> > - * @param _vector is the vector number of the interrupt to clear.
> > - *
> > - * @par Constraints
> > - * @parblock
> > - * The following constraints apply to this directive:
> > - *
> > - * * The directive is not implemented.
> > - * @endparblock
> > - */
> > -#define rtems_interrupt_clear( _vector ) do { } while ( 0 )
> > -
> >  /* Generated from spec:/rtems/intr/if/lock-initialize */
> >
> >  /**
> > @@ -909,6 +874,129 @@ rtems_status_code rtems_interrupt_catch(
> >  #define RTEMS_INTERRUPT_LOCK_REFERENCE( _designator, _target ) \
> >ISR_LOCK_REFERENCE( _designator, _target )
> >
> > +/* Generated from spec:/rtems/intr/if/cause */
> > +
> > +/**
> > + * @ingroup RTEMSAPIClassicIntr
> > + *
> > + * @brief Causes the interrupt vector.
> > + *
> > + * @param vector is the number of the interrupt vector to cause.
> > + *
> > + * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
> > + *
> > + * @retval ::RTEMS_INVALID_ID There was no interrupt vector associated 
> > with the
> > + *   number specified by ``vector``.
> > + *
> > + * @retval ::RTEMS_UNSATISFIED The request to cause the interrupt vector 
> > has
> > + *   not been satisfied.
> > + *
> > + * @par Notes
> > + * The rtems_interrupt_get_attributes() directive may be used to check if 
> > an
> > + * interrupt vector can be caused.
> > + *
> > + * @par Constraints
> > + * @parblock
> > + * The following constraints apply to this directive:
> > + *
> > + * * The directive may be called from within interrupt context.
> > + *
> > + * * The directive may be called from within device driver initialization
> > + *   context.
> > + *
> > + * * The directive may be called from within task context.
> > + *
> > + * * The directive will not cause the calling task to be preempted.
> > + * @endparblock
> > + */
> > +rtems_status_code rtems_interrupt_cause( rtems_vector_number vector );
> > +
> > +/* Generated from spec:/rtems/intr/if/cause-on */
> > +
> > +/**
> > + * @ingroup RTEMSAPIClassicIntr
> > + *
> > + * @brief Causes the interrupt vector on the processor.
> > + *
> > + * @param vector is the number of the interrupt vector to cause.
> > + *
> > + * @param cpu_index is the index of the target processor of the interrupt
> > + *   vector to cause.
> > + *
> > + * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
> > + *
> > + * @retval ::RTEMS_INVALID_ID There was no interrupt vector associated 
> > with the
> > + *   number specified by ``vector``.
> > + *
> > + * @retval ::RTEMS_NOT_CONFIGURED The processor specified by ``cpu_index`` 
> > was

Re: [PATCH 06/41] rtems: Add rtems_interrupt_get_attributes()

[Sebastian Huber]

On 21/07/2021 20:00, Gedare Bloom wrote:

+  /**
+   * @brief This member is true, if the interrupt vector may be enabled by
+   *   rtems_interrupt_vector_enable(), otherwise it is false.
+   *
+   * When an interrupt vector may be enabled, this means that the enabled state
+   * may be changed from disabled to enabled and from enabled to enabled.  The

s/may/might
It is more proper to say "might" when something "might not". "may" and
"can" are close synonyms, but "maybe" is closer to "might" in usage.
English is still terrible.



For the tests we need two variants. One (currently "can") for which it 
is certain that the operation is successful. Another one (currently 
"maybe") for which the the operation could be successful or unsatisfied.


For the "may_be_triggered_by_message" I would like to express that 
messages can trigger the interrupt, however, there may be also other 
triggers like signals or software.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 19/41] bsps/irq: Implement new directives for GICv2/3

[Gedare Bloom]

On Tue, Jul 13, 2021 at 5:47 PM Chris Johns  wrote:
>
> On 13/7/21 10:55 pm, Kinsey Moore wrote:
> > On 7/13/2021 00:16, Sebastian Huber wrote:
> >> On 13/07/2021 04:46, Kinsey Moore wrote:
>  index a1ba5e9112..6f5d4015e4 100644
>  --- a/bsps/shared/dev/irq/arm-gicv2.c
>  +++ b/bsps/shared/dev/irq/arm-gicv2.c
>  @@ -1,5 +1,5 @@
>    /*
>  - * Copyright (c) 2013, 2019 embedded brains GmbH.  All rights reserved.
>  + * Copyright (c) 2013, 2021 embedded brains GmbH.  All rights reserved.
> *
> *  embedded brains GmbH
> *  Dornierstr. 4
>  @@ -69,6 +69,28 @@ rtems_status_code bsp_interrupt_get_attributes(
>  rtems_interrupt_attributes *attributes
>    )
>    {
>  +  attributes->is_maskable = true;
>  +  attributes->maybe_enable = true;
>  +
>  +  if ( vector <= ARM_GIC_IRQ_SGI_LAST ) {
>  +attributes->always_enabled = true;
> >>>
> >>> As far as I'm aware, SGIs can be enabled or disabled using GICD_ISENABLER0
> >>> just like
> >>>
> >>> PPI or SPI interrupts for both GICv2 and GICv3. Section 3.1.2 of the GICv2
> >>> architecture
> >>>
> >>> spec (IHI0048B) references this, though I have seen implementations where
> >>> certain SGI
> >>>
> >>> and PPI interrupts are hard-wired enabled or disabled and that state 
> >>> can't be
> >>> changed
> >>>
> >>> (which is also covered in this section).
> >>
> >> Ok, on Qemu and the i.MX7D the SGI are always enabled. I would keep the
> >> attributes like this until we have a system which is different.
>
> Should a comment be added that says this?
>
Yes, in case someone else comes along to add support for a system that
is different, it will help to give them some pointers.

> >> I will remove
> >> the check in bsp_interrupt_vector_enable/disable(). So, in the worst case, 
> >> the
> >> attributes are wrong.
> > I only mention it because I've seen it on ZynqMP hardware. Interrupt enable 
> > bits
> > for interrupts 0-24 are locked with 0-7 permanently enabled and 8-24 
> > permanently
> > disabled. I think the QEMU GICv3 driver allows all SGIs to be enabled or
> > disabled. I tried to get more information about whether those bits can be
> > unlocked, but nothing has been forthcoming:
> > https://forums.xilinx.com/t5/Processor-System-Design-and-AXI/Zynq-Ultrascale-MPSoC-SGI-and-PPI-enable/td-p/1212370
>
> I do not know about the GIC but I know with the ARM debug hardware the
> implementers can wrap the IP in different ways and that means something that 
> is
> user controllable may be fixed in other implementation or brought out to
> external pins in another.
>
> Chris
> ___
> 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 19/41] bsps/irq: Implement new directives for GICv2/3

[Gedare Bloom]

On Wed, Jul 21, 2021 at 12:28 PM Sebastian Huber
 wrote:
>
> On 21/07/2021 20:25, Gedare Bloom wrote:
> > As far as I'm aware, SGIs can be enabled or disabled using 
> > GICD_ISENABLER0
> > just like
> >
> > PPI or SPI interrupts for both GICv2 and GICv3. Section 3.1.2 of the 
> > GICv2
> > architecture
> >
> > spec (IHI0048B) references this, though I have seen implementations 
> > where
> > certain SGI
> >
> > and PPI interrupts are hard-wired enabled or disabled and that state 
> > can't be
> > changed
> >
> > (which is also covered in this section).
>  Ok, on Qemu and the i.MX7D the SGI are always enabled. I would keep the
>  attributes like this until we have a system which is different.
> >> Should a comment be added that says this?
> >>
> > Yes, in case someone else comes along to add support for a system that
> > is different, it will help to give them some pointers.
>
> I addressed this with new attributes in the v2 patch versions:
>
> https://lists.rtems.org/pipermail/devel/2021-July/068276.html
>

Aha. Thanks. We currently prefer a full patch set post after review,
but this is fine with me. I would like to see the comment made in the
gic sources themselves where the attributes get initialized
specifically for this case of the SGI on these devices.

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] linker_set.h: Add alignof implementation for when not C11 or C++11

[Gedare Bloom]

This seems alright to me. At least, it should get some complaints
quickly if it doesn't work :)

On Tue, Jul 20, 2021 at 3:04 PM Joel Sherrill  wrote:
>
> The default implementation was completely broken. Use the GCC specific
> __alignof__ if compiling for C99 or C++03. If not C++11, C11, or
> GCC, then it is an error.
> ---
>  freebsd/sys/sys/linker_set.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/freebsd/sys/sys/linker_set.h b/freebsd/sys/sys/linker_set.h
> index baa5ae4..9af5307 100755
> --- a/freebsd/sys/sys/linker_set.h
> +++ b/freebsd/sys/sys/linker_set.h
> @@ -73,8 +73,10 @@
>#define RTEMS_BSD_ALIGNOF( _type_name ) alignof( _type_name )
>  #elif __STDC_VERSION__ >= 201112L
>#define RTEMS_BSD_ALIGNOF( _type_name ) _Alignof( _type_name )
> +#elif defined(__GNUC__)
> +  #define RTEMS_BSD_ALIGNOF( _type_name ) __alignof__( _type_name )
>  #else
> -  #define RTEMS_BSD_ALIGNOF( _type_name ) sizeof( _type_name )
> +  #error "FIX ME! Implement RTEMS_BSD_ALIGNOF() for this environment"
>  #endif
>
>  #define RTEMS_BSD_SET_ALIGN( type )\
> --
> 1.8.3.1
>
> ___
> 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 05/41] rtems: Generate

[Gedare Bloom]

On Mon, Jul 12, 2021 at 6:50 AM Sebastian Huber
 wrote:
>
> Use  which just provides the data types and avoid a
> dependency on  which contains the full chain
> implementation.
>
> Change license to BSD-2-Clause according to file histories and
> documentation re-licensing agreement.
>
> Update #3269.
> Update #3899.
> Update #3993.
> ---
>  cpukit/include/rtems/irq-extension.h | 1830 +++---
>  1 file changed, 1354 insertions(+), 476 deletions(-)
>
> diff --git a/cpukit/include/rtems/irq-extension.h 
> b/cpukit/include/rtems/irq-extension.h
> index 915be09e2b..5f24fb502e 100644
> --- a/cpukit/include/rtems/irq-extension.h
> +++ b/cpukit/include/rtems/irq-extension.h
> @@ -1,294 +1,566 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
>  /**
>   * @file
>   *
> - * @ingroup rtems_interrupt_extension
> + * @ingroup RTEMSAPIClassicIntr
>   *
> - * @brief Header file for the Interrupt Manager Extension.
> + * @brief This header file defines the Interrupt Manager Extension API.
> + */
> +
> +/*
> + * Copyright (C) 2008, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
>   */
>
>  /*
> - * Based on concepts of Pavel Pisa, Till Straumann and Eric Valette.

We lose some kind of historical record / attribution here. I wonder
if, based on the other discussion about sponsor attribution, there
should be something in the generated header for any non-copyright
attribution (e.g., if someone wants their authorship reflected)?

I don't think it matters so much. Those three guys have their
contributions well-reflected in other parts of RTEMS.

> + * This file is part of the RTEMS quality process and was automatically
> + * generated.  If you find something that needs to be fixed or
> + * worded better please post a report or patch to an RTEMS mailing list
> + * or raise a bug report:
> + *
> + * https://www.rtems.org/bugs.html
>   *
> - * Copyright (C) 2008, 2020 embedded brains GmbH 
> (http://www.embedded-brains.de)
> + * For information on updating and regenerating please refer to the How-To
> + * section in the Software Requirements Engineering chapter of the
> + * RTEMS Software Engineering manual.  The manual is provided as a part of
> + * a release.  For development sources please refer to the online
> + * documentation at:
>   *
> - * The license and distribution terms for this file may be
> - * found in the file LICENSE in this distribution or at
> - * http://www.rtems.org/license/LICENSE.
> + * https://docs.rtems.org
>   */
>
> -#ifndef RTEMS_IRQ_EXTENSION_H
> -#define RTEMS_IRQ_EXTENSION_H
> +/* Generated from spec:/rtems/intr/if/header-2 */
>
> -#include 
> -#include 
> +#ifndef _RTEMS_IRQ_EXTENSION_H
> +#define _RTEMS_IRQ_EXTENSION_H
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>
>  #ifdef __cplusplus
>  extern "C" {
> -#endif /* __cplusplus */
> +#endif
> +
> +/* Generated from spec:/rtems/intr/if/handler */
>
>  /**
> - * @defgroup rtems_interrupt_extension Interrupt Manager Extension
> - *
>   * @ingroup RTEMSAPIClassicIntr
>   *
> - * In addition to the Classic API interrupt handler with a handle are
> - * supported.  You can also install multiple shared handler for one interrupt
> - * vector.
> + * @brief Interrupt handler routines shall have this type.
>   */
> -/**@{**/
> +typedef void ( *rtems_interrupt_handler )( void * );
> +
> +/* Generated from spec:/rtems/intr/if/per-handler-routine */
>
>  /**
> - * @brief Makes the interrupt handler unique.  Prevents other handler from
> - * using the same interrupt vector.
> + * @ingroup 

Re: [PATCH 04/41] rtems: Add rtems_interrupt_cause_on()

[Sebastian Huber]

On 21/07/2021 19:43, Gedare Bloom wrote:

Before we bake this into the API forever, I want to ask if "cause" is
the right word to use here? Often, "interrupt cause" is thought of as
a noun to mean what caused the interrupt, while the verb is usually
"raise" or post, trigger, etc. Because "cause" is both a noun and a
verb that mean something in this context, it may be better to use a
different verb. English is pretty much terrible.

I don't have a major problem with sticking to "cause" but thought I'd
bring this up.


I just used the existing (not implemented) directive. We can also use 
rtems_interrupt_raise() (similar to the signal raise()). In this case we 
should remove rtems_interrupt_cause().


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 15/41] bsps/irq: bsp_interrupt_vector_enable()

[Gedare Bloom]

On Mon, Jul 12, 2021 at 6:50 AM Sebastian Huber
 wrote:
>
> Return a status code for bsp_interrupt_vector_enable().
>
> Update #3269.
> ---
>  bsps/arm/beagle/irq/irq.c |  3 ++-
>  bsps/arm/csb336/irq/irq.c |  4 +++-
>  bsps/arm/csb337/irq/irq.c |  3 ++-
>  bsps/arm/edb7312/irq/irq.c|  4 +++-
>  bsps/arm/gumstix/irq/irq.c|  3 ++-
>  bsps/arm/lpc24xx/irq/irq.c|  3 ++-
>  bsps/arm/lpc32xx/irq/irq.c|  4 +++-
>  bsps/arm/raspberrypi/irq/irq.c|  3 ++-
>  bsps/arm/rtl22xx/irq/irq.c|  3 ++-
>  bsps/arm/shared/irq/irq-armv7m.c  |  3 ++-
>  bsps/arm/smdk2410/irq/irq.c   |  3 ++-
>  bsps/arm/tms570/irq/irq.c |  3 ++-
>  bsps/i386/shared/irq/irq.c|  3 ++-
>  bsps/include/bsp/irq-generic.h| 16 ++--
>  bsps/lm32/shared/irq/irq.c|  3 ++-
>  bsps/m68k/genmcf548x/irq/irq.c|  4 +++-
>  bsps/mips/shared/irq/irq.c|  3 ++-
>  bsps/powerpc/gen5200/irq/irq.c|  4 +++-
>  bsps/powerpc/gen83xx/irq/irq.c|  4 +++-
>  bsps/powerpc/mpc55xxevb/start/irq.c   |  3 ++-
>  bsps/powerpc/mpc8260ads/irq/irq.c |  4 +++-
>  bsps/powerpc/psim/irq/irq_init.c  |  3 ++-
>  bsps/powerpc/qemuppc/irq/irq_init.c   |  3 ++-
>  bsps/powerpc/qoriq/irq/irq.c  |  5 +++--
>  bsps/powerpc/shared/irq/ppc-irq-generic.c |  3 ++-
>  bsps/powerpc/t32mppc/irq/irq.c|  3 ++-
>  bsps/powerpc/tqm8xx/irq/irq.c |  4 +++-
>  bsps/powerpc/virtex/irq/irq_init.c|  4 +++-
>  bsps/riscv/griscv/irq/irq.c   |  3 ++-
>  bsps/riscv/riscv/irq/irq.c|  4 +++-
>  bsps/shared/dev/irq/arm-gicv2.c   |  3 ++-
>  bsps/shared/dev/irq/arm-gicv3.c   |  4 +++-
>  bsps/shared/irq/irq-default.c |  3 ++-
>  bsps/shared/irq/irq-enable-disable.c  |  4 +---
>  bsps/sparc/leon3/start/eirq.c |  3 ++-
>  bsps/sparc/shared/irq/irq-shared.c|  3 ++-
>  bsps/x86_64/amd64/interrupts/idt.c|  3 ++-
>  37 files changed, 93 insertions(+), 45 deletions(-)
>
> diff --git a/bsps/arm/beagle/irq/irq.c b/bsps/arm/beagle/irq/irq.c
> index e34a89afff..7953a2fe1f 100644
> --- a/bsps/arm/beagle/irq/irq.c
> +++ b/bsps/arm/beagle/irq/irq.c
> @@ -137,7 +137,7 @@ rtems_status_code bsp_interrupt_vector_is_enabled(
>return RTEMS_UNSATISFIED;
>  }
>
> -void bsp_interrupt_vector_enable(rtems_vector_number vector)
> +rtems_status_code bsp_interrupt_vector_enable(rtems_vector_number vector)
>  {
>uint32_t mask, cur;
>uint32_t mir_reg = omap_get_mir_reg(vector, );
> @@ -147,6 +147,7 @@ void bsp_interrupt_vector_enable(rtems_vector_number 
> vector)
>cur = mmio_read(omap_intr.base + mir_reg);
>mmio_write(omap_intr.base + mir_reg, cur & ~mask);
>flush_data_cache();
> +  return RTEMS_SUCCESSFUL;
>  }
>
>  void bsp_interrupt_vector_disable(rtems_vector_number vector)
> diff --git a/bsps/arm/csb336/irq/irq.c b/bsps/arm/csb336/irq/irq.c
> index 13f094e1fb..d47f0362e8 100644
> --- a/bsps/arm/csb336/irq/irq.c
> +++ b/bsps/arm/csb336/irq/irq.c
> @@ -68,12 +68,14 @@ rtems_status_code bsp_interrupt_vector_is_enabled(
>return RTEMS_UNSATISFIED;
>  }
>
> -void bsp_interrupt_vector_enable(rtems_vector_number vector)
> +rtems_status_code bsp_interrupt_vector_enable(rtems_vector_number vector)
>  {
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
>
>if (vector < MC9328MXL_NUM_INTS)
>  MC9328MXL_AITC_INTENNUM = vector;
> +
> +  return RTEMS_SUCCESSFUL;
>  }
>
>  void bsp_interrupt_vector_disable(rtems_vector_number vector)
> diff --git a/bsps/arm/csb337/irq/irq.c b/bsps/arm/csb337/irq/irq.c
> index 1b13f0b461..a4bfb1f83b 100644
> --- a/bsps/arm/csb337/irq/irq.c
> +++ b/bsps/arm/csb337/irq/irq.c
> @@ -69,10 +69,11 @@ rtems_status_code bsp_interrupt_vector_is_enabled(
>return RTEMS_UNSATISFIED;
>  }
>
> -void bsp_interrupt_vector_enable(rtems_vector_number vector)
> +rtems_status_code bsp_interrupt_vector_enable(rtems_vector_number vector)
>  {
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
>AIC_CTL_REG(AIC_IECR) = 1 << vector;
> +  return RTEMS_SUCCESSFUL;
>  }
>
>  void bsp_interrupt_vector_disable(rtems_vector_number vector)
> diff --git a/bsps/arm/edb7312/irq/irq.c b/bsps/arm/edb7312/irq/irq.c
> index 75dffdec9f..3cff5bfff2 100644
> --- a/bsps/arm/edb7312/irq/irq.c
> +++ b/bsps/arm/edb7312/irq/irq.c
> @@ -69,7 +69,7 @@ rtems_status_code bsp_interrupt_vector_is_enabled(
>return RTEMS_UNSATISFIED;
>  }
>
> -void bsp_interrupt_vector_enable(rtems_vector_number vector)
> +rtems_status_code bsp_interrupt_vector_enable(rtems_vector_number vector)
>  {
>  bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
>
> @@ -93,6 +93,8 @@ void bsp_interrupt_vector_enable(rtems_vector_number vector)
>  /* interrupt managed by 

Re: [PATCH 16/41] bsps/irq: bsp_interrupt_vector_disable()

[Gedare Bloom]

On Mon, Jul 12, 2021 at 6:51 AM Sebastian Huber
 wrote:
>
> Return a status code for bsp_interrupt_vector_disable().
>
> Update #3269.
> ---
>  bsps/arm/beagle/irq/irq.c |  3 ++-
>  bsps/arm/csb336/irq/irq.c |  4 +++-
>  bsps/arm/csb337/irq/irq.c |  3 ++-
>  bsps/arm/edb7312/irq/irq.c|  4 +++-
>  bsps/arm/gumstix/irq/irq.c|  3 ++-
>  bsps/arm/lpc24xx/irq/irq.c|  3 ++-
>  bsps/arm/lpc32xx/irq/irq.c|  4 +++-
>  bsps/arm/raspberrypi/irq/irq.c|  3 ++-
>  bsps/arm/rtl22xx/irq/irq.c|  3 ++-
>  bsps/arm/shared/irq/irq-armv7m.c  |  3 ++-
>  bsps/arm/smdk2410/irq/irq.c   |  3 ++-
>  bsps/arm/tms570/irq/irq.c |  3 ++-
>  bsps/i386/shared/irq/irq.c|  3 ++-
>  bsps/include/bsp/irq-generic.h| 16 ++--
>  bsps/lm32/shared/irq/irq.c|  3 ++-
>  bsps/m68k/genmcf548x/irq/irq.c|  4 +++-
>  bsps/mips/shared/irq/irq.c|  3 ++-
>  bsps/powerpc/gen5200/irq/irq.c|  4 +++-
>  bsps/powerpc/gen83xx/irq/irq.c|  4 +++-
>  bsps/powerpc/mpc55xxevb/start/irq.c   |  3 ++-
>  bsps/powerpc/mpc8260ads/irq/irq.c |  4 +++-
>  bsps/powerpc/psim/irq/irq_init.c  |  3 ++-
>  bsps/powerpc/qemuppc/irq/irq_init.c   |  3 ++-
>  bsps/powerpc/qoriq/irq/irq.c  |  5 +++--
>  bsps/powerpc/shared/irq/ppc-irq-generic.c |  3 ++-
>  bsps/powerpc/t32mppc/irq/irq.c|  3 ++-
>  bsps/powerpc/tqm8xx/irq/irq.c |  4 +++-
>  bsps/powerpc/virtex/irq/irq_init.c|  4 +++-
>  bsps/riscv/griscv/irq/irq.c   |  3 ++-
>  bsps/riscv/riscv/irq/irq.c|  4 +++-
>  bsps/shared/dev/irq/arm-gicv2.c   |  3 ++-
>  bsps/shared/dev/irq/arm-gicv3.c   |  4 +++-
>  bsps/shared/irq/irq-default.c |  3 ++-
>  bsps/shared/irq/irq-enable-disable.c  |  4 +---
>  bsps/sparc/leon3/start/eirq.c |  3 ++-
>  bsps/sparc/shared/irq/irq-shared.c|  3 ++-
>  bsps/x86_64/amd64/interrupts/idt.c|  3 ++-
>  37 files changed, 93 insertions(+), 45 deletions(-)
>
> diff --git a/bsps/arm/beagle/irq/irq.c b/bsps/arm/beagle/irq/irq.c
> index 7953a2fe1f..7db3428499 100644
> --- a/bsps/arm/beagle/irq/irq.c
> +++ b/bsps/arm/beagle/irq/irq.c
> @@ -150,7 +150,7 @@ rtems_status_code 
> bsp_interrupt_vector_enable(rtems_vector_number vector)
>return RTEMS_SUCCESSFUL;
>  }
>
> -void bsp_interrupt_vector_disable(rtems_vector_number vector)
> +rtems_status_code bsp_interrupt_vector_disable(rtems_vector_number vector)
>  {
>uint32_t mask, cur;
>uint32_t mir_reg = omap_get_mir_reg(vector, );
> @@ -160,6 +160,7 @@ void bsp_interrupt_vector_disable(rtems_vector_number 
> vector)
>cur = mmio_read(omap_intr.base + mir_reg);
>mmio_write(omap_intr.base + mir_reg, cur | mask);
>flush_data_cache();
> +  return RTEMS_SUCCESSFUL;
>  }
>
>  rtems_status_code bsp_interrupt_facility_initialize(void)
> diff --git a/bsps/arm/csb336/irq/irq.c b/bsps/arm/csb336/irq/irq.c
> index d47f0362e8..2cf142100a 100644
> --- a/bsps/arm/csb336/irq/irq.c
> +++ b/bsps/arm/csb336/irq/irq.c
> @@ -78,12 +78,14 @@ rtems_status_code 
> bsp_interrupt_vector_enable(rtems_vector_number vector)
>return RTEMS_SUCCESSFUL;
>  }
>
> -void bsp_interrupt_vector_disable(rtems_vector_number vector)
> +rtems_status_code bsp_interrupt_vector_disable(rtems_vector_number vector)
>  {
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
>
>if (vector < MC9328MXL_NUM_INTS)
>  MC9328MXL_AITC_INTDISNUM = vector;
> +
> +  return RTEMS_SUCCESSFUL;
>  }
>
>  rtems_status_code bsp_interrupt_facility_initialize(void)
> diff --git a/bsps/arm/csb337/irq/irq.c b/bsps/arm/csb337/irq/irq.c
> index a4bfb1f83b..b999841751 100644
> --- a/bsps/arm/csb337/irq/irq.c
> +++ b/bsps/arm/csb337/irq/irq.c
> @@ -76,10 +76,11 @@ rtems_status_code 
> bsp_interrupt_vector_enable(rtems_vector_number vector)
>return RTEMS_SUCCESSFUL;
>  }
>
> -void bsp_interrupt_vector_disable(rtems_vector_number vector)
> +rtems_status_code bsp_interrupt_vector_disable(rtems_vector_number vector)
>  {
>bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
>AIC_CTL_REG(AIC_IDCR) = 1 << vector;
> +  return RTEMS_SUCCESSFUL;
>  }
>
>  rtems_status_code bsp_interrupt_facility_initialize(void)
> diff --git a/bsps/arm/edb7312/irq/irq.c b/bsps/arm/edb7312/irq/irq.c
> index 3cff5bfff2..ec50443775 100644
> --- a/bsps/arm/edb7312/irq/irq.c
> +++ b/bsps/arm/edb7312/irq/irq.c
> @@ -97,7 +97,7 @@ rtems_status_code 
> bsp_interrupt_vector_enable(rtems_vector_number vector)
>  return RTEMS_SUCCESSFUL;
>  }
>
> -void bsp_interrupt_vector_disable(rtems_vector_number vector)
> +rtems_status_code bsp_interrupt_vector_disable(rtems_vector_number vector)
>  {
>  bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));
>
> @@ -121,6 +121,8 

[PATCH] build: Add "family/" prefix to BSP familiy enable

[Sebastian Huber]

BSP family and BSP variant names may be equal.  This prefix avoids
ambiguity in the enabled-by expressions.
---
 wscript | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wscript b/wscript
index f27dba6831..b7a0412150 100755
--- a/wscript
+++ b/wscript
@@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, 
top_group, variant):
 conf.env["ENABLE"] = [
 get_compiler(conf, cp, variant),
 arch,
-arch_family,
+"family/" + arch_family,
 arch_bsp,
 ]
 
-- 
2.26.2

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

Re: [PATCH 20/41] sparc/irq: Implement new interrupt directives

[Gedare Bloom]

On Wed, Jul 21, 2021 at 12:31 PM Sebastian Huber
 wrote:
>
> On 21/07/2021 20:28, Gedare Bloom wrote:
> > Why not throw an error here instead? In production, you wouldn't want
> > this code...
>
> The main issue is the bad chip design. If we don't have this code, we
> can't test the extended interrupts. In production, you want tested code.
>

ok, thanks. My comments are all pretty minor, except for the
terminology issues of "cause" but that wording already exists. post
the v2 series, but I probably won't review it and you can check it in
if no one complains. It's up to you if you want to work a different
wording than "cause" -- I prefer "raise"
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 05/41] rtems: Generate

[Sebastian Huber]

On 21/07/2021 19:50, Gedare Bloom wrote:

  /*
- * Based on concepts of Pavel Pisa, Till Straumann and Eric Valette.

We lose some kind of historical record / attribution here. I wonder
if, based on the other discussion about sponsor attribution, there
should be something in the generated header for any non-copyright
attribution (e.g., if someone wants their authorship reflected)?

I don't think it matters so much. Those three guys have their
contributions well-reflected in other parts of RTEMS.



The concept of the interrupt manager extension API is based on a mailing 
list discussion. From my point of view there is no copyrightable content 
from these three persons in the header file. With respect to the 
attribution, I would be in favour of a general RTEMS contributors file. 
We already have something like this in "c/ACKNOWLEDGEMENTS", but it is 
not up to date.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 13/41] bsps/irq: Add rtems_interrupt_get_attributes()

[Sebastian Huber]

On 21/07/2021 20:14, Gedare Bloom wrote:

+  memset( attributes, 0, sizeof( *attributes ) );
+
+  if ( !bsp_interrupt_is_valid_vector( vector ) ) {
+return RTEMS_INVALID_ID;
+  }

I think do the error checking first, before changing the out parameters?


Some users ignore return values. This way they get at least a 
deterministic result from the directive.  See:


https://lists.rtems.org/pipermail/devel/2021-March/065840.html


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 41/41] validation: Test rtems_interrupt_set_affinity()

[Gedare Bloom]

I did not check the validation patches, everything else looks good to me.

On Mon, Jul 12, 2021 at 6:51 AM Sebastian Huber
 wrote:
>
> Update #3269.
> ---
>  .../testsuites/validation/validation-0.yml|   1 +
>  testsuites/validation/tc-intr-set-affinity.c  | 670 ++
>  2 files changed, 671 insertions(+)
>  create mode 100644 testsuites/validation/tc-intr-set-affinity.c
>
> diff --git a/spec/build/testsuites/validation/validation-0.yml 
> b/spec/build/testsuites/validation/validation-0.yml
> index 89c0f408d6..6778a5ec25 100644
> --- a/spec/build/testsuites/validation/validation-0.yml
> +++ b/spec/build/testsuites/validation/validation-0.yml
> @@ -23,6 +23,7 @@ source:
>  - testsuites/validation/tc-intr-get-affinity.c
>  - testsuites/validation/tc-intr-get-attributes.c
>  - testsuites/validation/tc-intr-is-pending.c
> +- testsuites/validation/tc-intr-set-affinity.c
>  - testsuites/validation/tc-intr-vector-disable.c
>  - testsuites/validation/tc-intr-vector-enable.c
>  - testsuites/validation/tc-intr-vector-is-enabled.c
> diff --git a/testsuites/validation/tc-intr-set-affinity.c 
> b/testsuites/validation/tc-intr-set-affinity.c
> new file mode 100644
> index 00..b2b47baea8
> --- /dev/null
> +++ b/testsuites/validation/tc-intr-set-affinity.c
> @@ -0,0 +1,670 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSTestCaseRtemsIntrReqSetAffinity
> + */
> +
> +/*
> + * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/*
> + * This file is part of the RTEMS quality process and was automatically
> + * generated.  If you find something that needs to be fixed or
> + * worded better please post a report or patch to an RTEMS mailing list
> + * or raise a bug report:
> + *
> + * https://www.rtems.org/bugs.html
> + *
> + * For information on updating and regenerating please refer to the How-To
> + * section in the Software Requirements Engineering chapter of the
> + * RTEMS Software Engineering manual.  The manual is provided as a part of
> + * a release.  For development sources please refer to the online
> + * documentation at:
> + *
> + * https://docs.rtems.org
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +
> +#include "tx-support.h"
> +
> +#include 
> +
> +/**
> + * @defgroup RTEMSTestCaseRtemsIntrReqSetAffinity \
> + *   spec:/rtems/intr/req/set-affinity
> + *
> + * @ingroup RTEMSTestSuiteTestsuitesValidation0
> + *
> + * @{
> + */
> +
> +typedef enum {
> +  RtemsIntrReqSetAffinity_Pre_Vector_Valid,
> +  RtemsIntrReqSetAffinity_Pre_Vector_Invalid,
> +  RtemsIntrReqSetAffinity_Pre_Vector_NA
> +} RtemsIntrReqSetAffinity_Pre_Vector;
> +
> +typedef enum {
> +  RtemsIntrReqSetAffinity_Pre_CPUSetKind_Valid,
> +  RtemsIntrReqSetAffinity_Pre_CPUSetKind_Huge,
> +  RtemsIntrReqSetAffinity_Pre_CPUSetKind_Askew,
> +  RtemsIntrReqSetAffinity_Pre_CPUSetKind_NA
> +} RtemsIntrReqSetAffinity_Pre_CPUSetKind;
> +
> +typedef enum {
> +  RtemsIntrReqSetAffinity_Pre_CPUSet_Valid,
> +  RtemsIntrReqSetAffinity_Pre_CPUSet_Null,
> +  RtemsIntrReqSetAffinity_Pre_CPUSet_NA
> +} RtemsIntrReqSetAffinity_Pre_CPUSet;
> +
> +typedef enum {
> +  RtemsIntrReqSetAffinity_Pre_CanSetAffinity_Yes,
> +  RtemsIntrReqSetAffinity_Pre_CanSetAffinity_No,
> +  RtemsIntrReqSetAffinity_Pre_CanSetAffinity_NA
> +} RtemsIntrReqSetAffinity_Pre_CanSetAffinity;
> +
> +typedef enum {
> +  RtemsIntrReqSetAffinity_Post_Status_Ok,
> +  RtemsIntrReqSetAffinity_Post_Status_InvAddr,
> +  RtemsIntrReqSetAffinity_Post_Status_InvId,
> +  

Re: [PATCH 13/41] bsps/irq: Add rtems_interrupt_get_attributes()

[Gedare Bloom]

Thank you for the clarification. I knew we discussed this recently and
didn't recall the outcome. This is fine, we can be nicer than (say)
compiler writers :)

On Wed, Jul 21, 2021 at 12:21 PM Sebastian Huber
 wrote:
>
> On 21/07/2021 20:14, Gedare Bloom wrote:
> >> +  memset( attributes, 0, sizeof( *attributes ) );
> >> +
> >> +  if ( !bsp_interrupt_is_valid_vector( vector ) ) {
> >> +return RTEMS_INVALID_ID;
> >> +  }
> > I think do the error checking first, before changing the out parameters?
>
> Some users ignore return values. This way they get at least a
> deterministic result from the directive.  See:
>
> https://lists.rtems.org/pipermail/devel/2021-March/065840.html
>
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 20/41] sparc/irq: Implement new interrupt directives

[Sebastian Huber]

On 21/07/2021 21:04, Gedare Bloom wrote:

On Wed, Jul 21, 2021 at 12:31 PM Sebastian Huber
  wrote:

On 21/07/2021 20:28, Gedare Bloom wrote:

Why not throw an error here instead? In production, you wouldn't want
this code...

The main issue is the bad chip design. If we don't have this code, we
can't test the extended interrupts. In production, you want tested code.


ok, thanks. My comments are all pretty minor, except for the
terminology issues of "cause" but that wording already exists. post
the v2 series, but I probably won't review it and you can check it in
if no one complains. It's up to you if you want to work a different
wording than "cause" -- I prefer "raise"


Thanks a lot for the review.

Joel, what is your opinion with respect to "cause" vs. "raise"?

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 20/41] sparc/irq: Implement new interrupt directives

[Sebastian Huber]

On 21/07/2021 20:28, Gedare Bloom wrote:

Why not throw an error here instead? In production, you wouldn't want
this code...


The main issue is the bad chip design. If we don't have this code, we 
can't test the extended interrupts. In production, you want tested code.





+rtems_interrupt_lock_context lock_context;
+
+/*
+ * This is a very dangerous operation and should only be used for test
+ * software.  We may accidentally clear the pending state set by
+ * peripherals with this read-modify-write operation.
+ */
+LEON3_IRQCTRL_ACQUIRE(_context);
+LEON3_IrqCtrl_Regs->ipend |= bit;
+LEON3_IRQCTRL_RELEASE(_context);
+  }
+
+  return RTEMS_SUCCESSFUL;
  }


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add the BSP family to the enable set

[Gedare Bloom]

On Tue, Jul 20, 2021 at 6:52 PM Chris Johns  wrote:
>
>
>
> On 20/7/21 8:25 pm, Sebastian Huber wrote:
> > On 15/07/2021 08:19, Sebastian Huber wrote:
> >> This makes it possible to use the BSP family in expressions of the 
> >> enabled-by
> >> attribute.
> >> ---
> >>   wscript | 7 ++-
> >>   1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/wscript b/wscript
> >> index 487951fdba..1331ae149e 100755
> >> --- a/wscript
> >> +++ b/wscript
> >> @@ -1387,7 +1387,12 @@ def configure_variant(conf, cp, bsp_map, path_list,
> >> top_group, variant):
> >> # For the enabled-by evaluation we have to use the base BSP 
> >> defined by
> >> the
> >>   # build specification and not the BSP name provided by the user.
> >> -conf.env["ENABLE"] = [get_compiler(conf, cp, variant), arch, arch_bsp]
> >> +conf.env["ENABLE"] = [
> >> +get_compiler(conf, cp, variant),
> >> +arch,
> >> +arch_family,
> >> +arch_bsp,
> >> +]
> >> conf.env["TOP"] = conf.path.abspath()
> >>   conf.env["TOPGROUP"] = top_group
> >
> > This actually broke some riscv BSPs which do not support SMP. We have
> >
> > cat spec/build/cpukit/optsmp.yml
> > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> > actions:
> > - get-boolean: null
> > - env-enable: null
> > - define-condition: null
> > build-type: option
> > copyrights:
> > - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> > default: false
> > default-by-family: []
> > default-by-variant: []
> > description: |
> >   Enable the Symmetric Multiprocessing (SMP) support
> > enabled-by:
> > - arm/altcycv_devkit
> > - arm/fvp_cortex_r52
> > - arm/imx7
> > - arm/raspberrypi2
> > - arm/realview_pbx_a9_qemu
> > - arm/xilinx_zynq_a9_qemu
> > - arm/xilinx_zynqmp_ultra96
> > - arm/xilinx_zynq_zc702
> > - arm/xilinx_zynq_zc706
> > - arm/xilinx_zynq_zedboard
> > - powerpc/qoriq_e500
> > - powerpc/qoriq_e6500_32
> > - powerpc/qoriq_e6500_64
> > - riscv/griscv
> > - riscv/grv32imac
> > - riscv/grv32imafdc
> > - riscv/rv32iac
> > - riscv/rv32imac
> > - riscv/rv32imafc
> > - riscv/rv32imafd
> > - riscv/rv32imafdc
> > - riscv/rv64imac
> > - riscv/rv64imac_medany
> > - riscv/rv64imafd
> > - riscv/rv64imafdc
> > - riscv/rv64imafdc_medany
> > - riscv/rv64imafd_medany
> > - sparc/erc32
> > - sparc/gr712rc
> > - sparc/gr740
> > - sparc/leon3
> > links: []
> > name: RTEMS_SMP
> > type: build
> >
> > The problem is that one BSP which supports SMP "riscv/griscv" is identical 
> > to
> > the family "riscv/griscv" which contains BSPs which do not support SMP
> > ("riscv/grv32i" and riscv/grv32im").
>
> Hmm, tricky. Can the BSPs that do not support SMP disable SMP in the BSP
> specific config, ie override/specialise in the BSP?
>

Or, can we avoid having duplication between BSP names and family names?

> Chris
> ___
> 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: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

[Vijay Kumar Banerjee]

Hi,


On Wed, Jul 21, 2021 at 2:25 AM Pavel Pisa  wrote:
>
> Hello Vijay,
>
> thanks of the status.
>

I added a note in the devel page: https://devel.rtems.org/wiki/Packages/LWIP



> On Wednesday 21 of July 2021 07:16:51 Vijay Kumar Banerjee wrote:
> > Hi Pavel,
> >
> > On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa  wrote:
> > > Is it devel branch of  Vijay Kumar Banerjee's
> > > repo
> > >
> > >   https://git.rtems.org/vijay/rtems-lwip.git/
> >
> > Right now yes. Once this is mature, it will probably be pushed to the
> > top directory.
> >
> > > If so, it would worth to put that on the top
> > > of LwIP RTEMS info page to guide people interested
> > > to live work and not lose time in another
> > > abandonned attempts
> > >
> > >   https://devel.rtems.org/wiki/Packages/LWIP
> >
> > Thanks, I'll add a note there.
> >
> > > Addition of pointers to STM WIP to some
> > > central place would worth too with
> > > pointer to the instructions or instructions
> > > included...
> >
> > I haven't tested it myself. Robin is working on this one and might be
> > able to add the instructions. But this is supposed to be merged into
> > the repo you mentioned above.
>
> Great that there is the common merge place.
>
>
> > > Generally I am curious what works and where
> > > are problems. I do not expect to have time or
> > > find students this summer but I try to offer
> > > project as theses and next summer and there
> > > chance (small) that I find some studnet
> > > to participate.
> >
> > I am currently actively working on the lwip port to get it working
> > with at least a few boards, along with a streamlined build system. I
> > could only get the BBB running with a telnetd application that I added
> > in the test/ directory in the rtems-lwip repository. I used the
> > drivers from TI for BBB.
>
> OK, I have some access to BBB so when my or some studnet
> time allows we can test it on this target.
Thanks. Any feedback would be really appreciated.

> I am more personally interested to TMS570.
> I think that I can find some time for testing on TMS570LS3137
> if the instructions and code is declared to worth to test.
> I hope that I have all tools for this setup.
>
This has not been tested yet, I'm working on the build system to
streamline the process further. It would be great to get this port
tested. Please ping me if you have any build issues when testing (if
you happen to test before the build system update :) ).


> =
> Side note to TMS570 FEE CTU code (if there is interest,
> I it would worth to move to separate thread)
>
> By the way, the way my former colleagues who left faculty
> stopped blocking (after many years) TMS570 Rapid Prototyping
> Platform code
>   http://rtime.felk.cvut.cz/rpp-tms570/
> and changed master branch license to MIT (The work has been
> exploited to gain money from their industrial partners and has
> little value for them now). Code was and is licensed under our
> faculty name and I can legally show it to third parties now
> and  try to find arrangement to share my and my students effort
> with community.
>
> There is XCP https://en.wikipedia.org/wiki/XCP_(protocol)
> loader implemented on FreeRTOS base which allows to update
> firmware over ETHERNET so it can be used as boot block for
> RTEMS. It can make RTEMS support testing and even continuous
> integration much easier. When RTEMS is run from SDRAM it
> would prevent Flash wear-out, important for TMS570,
> because guaranteed erase cycles are limited.
>
> Then there is support for lot of the TMS570 peripherals
> in the state twisted with HalCoGen, not directly usable,
> but valuable as reference. Lot of Matlab/Simulink glue
> which can be reused with minimal changes and  N2HET and
> DMA based "HW" implementation of time triggered CAN
> transfers with clock scaling and synchronization.
>
> So if there is interest, I can provide more information
> and collect it in RTEMS Wiki or on
>
>   Open Technologies Research Education and Exchange Services
>   https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
>
> pages, which are intended primarily for cooperation with
> our students.
>
> As for original RTIME wiki and documentation (even documenting
> RTEMS and GNU/Linux work shared from my company, done with studnets,
> myself at home), I do not expect to contribute to it any more.
> Even that substantial part is result of my 25 years of investent
> to that group but its leaders took it with them to another
> place with end expressed strong will/command to not contact
> "their" people anymore. Most of them have left them anyway
> so no problem to ask them for advises and help directly.
> =
> Back to LwIP
>
> Extending loader and OpenOCD support for TMS570LC4357
> is another target long-term on my list.
>
I'm interested in TMS570LC4357 and would like to you join efforts on this one.

> Back to LwIP, I see some your effort to 

[PATCH rtems.git v2] bsp: Remove fatal from exit(0). Add extended heap error output

[chrisj]

From: Chris Johns 

---
 bsps/shared/start/bspfatal-default.c | 83 +++-
 1 file changed, 70 insertions(+), 13 deletions(-)

diff --git a/bsps/shared/start/bspfatal-default.c 
b/bsps/shared/start/bspfatal-default.c
index 0289dbda63..84ca7e5cee 100644
--- a/bsps/shared/start/bspfatal-default.c
+++ b/bsps/shared/start/bspfatal-default.c
@@ -22,21 +22,42 @@ void bsp_fatal_extension(
 {
   #if BSP_VERBOSE_FATAL_EXTENSION
 Thread_Control *executing;
+const char* TYPE = "*** FATAL ***";
+const char* type = "fatal";
+
+if ( source == RTEMS_FATAL_SOURCE_EXIT ) {
+  if ( code == 0 ) {
+TYPE = "[ RTEMS shutdown ]";
+  } else {
+TYPE = "*** EXIT STATUS NOT ZERO ***";
+  }
+  type = "exit";
+}
 
 printk(
   "\n"
-  "*** FATAL ***\n"
-  "fatal source: %i (%s)\n"
-  #ifdef RTEMS_SMP
-"CPU: %" PRIu32 "\n"
-  #endif
+  "%s\n"
   ,
-  source,
-  rtems_fatal_source_text( source )
-  #ifdef RTEMS_SMP
-, rtems_scheduler_get_processor()
-  #endif
+  TYPE
 );
+
+if ( source != RTEMS_FATAL_SOURCE_EXIT || code != 0 ) {
+  printk(
+"%s source: %i (%s)\n"
+,
+type,
+source,
+rtems_fatal_source_text( source )
+  );
+}
+
+#ifdef RTEMS_SMP
+  printk(
+"CPU: %" PRIu32 "\n"
+,
+rtems_scheduler_get_processor()
+  );
+#endif
   #endif
 
   #if (BSP_PRINT_EXCEPTION_CONTEXT) || BSP_VERBOSE_FATAL_EXTENSION
@@ -48,13 +69,49 @@ void bsp_fatal_extension(
   #if BSP_VERBOSE_FATAL_EXTENSION
 else if ( source == INTERNAL_ERROR_CORE ) {
   printk(
-"fatal code: %ju (%s)\n",
+"%s code: %ju (%s)\n",
+type,
 (uintmax_t) code,
 rtems_internal_error_text( code )
   );
-} else {
+} else if ( source == RTEMS_FATAL_SOURCE_HEAP ) {
+  Heap_Error_context *error_context = (Heap_Error_context*) code;
+  const char* reasons[] = {
+"HEAP_ERROR_BROKEN_PROTECTOR",
+"HEAP_ERROR_FREE_PATTERN",
+"HEAP_ERROR_DOUBLE_FREE",
+"HEAP_ERROR_BAD_USED_BLOCK",
+"HEAP_ERROR_BAD_FREE_BLOCK"
+  };
+  const char* reason = "invalid reason";
+  if ( error_context->reason <= (int) HEAP_ERROR_BAD_FREE_BLOCK ) {
+reason = reasons[(int) error_context->reason];
+  }
+  printk(
+"heap error: heap=%p block=%p reason=%s(%d)",
+error_context->heap,
+error_context->block,
+reason,
+error_context->reason
+  );
+  if ( error_context->reason == HEAP_ERROR_BROKEN_PROTECTOR ) {
+uintptr_t *pb0 = _context->block->Protection_begin.protector [0];
+uintptr_t *pb1 = _context->block->Protection_begin.protector [1];
+uintptr_t *pe0 = _context->block->Protection_end.protector [0];
+uintptr_t *pe1 = _context->block->Protection_end.protector [1];
+printk(
+  "=[%p,%p,%p,%p]",
+  *pb0 != HEAP_BEGIN_PROTECTOR_0 ? pb0 : NULL,
+  *pb1 != HEAP_BEGIN_PROTECTOR_1 ? pb1 : NULL,
+  *pe0 != HEAP_END_PROTECTOR_0 ? pe0 : NULL,
+  *pe1 != HEAP_END_PROTECTOR_1 ? pe1 : NULL
+);
+printk( "\n" );
+  }
+} else if ( source != RTEMS_FATAL_SOURCE_EXIT || code != 0 ) {
   printk(
-"fatal code: %ju (0x%08jx)\n",
+"%s code: %ju (0x%08jx)\n",
+type,
 (uintmax_t) code,
 (uintmax_t) code
   );
-- 
2.24.1

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

Re: [PATCH] bsp: Remove fatal from exit(0). Add extended heap error output

[Joel Sherrill]

On Wed, Jul 21, 2021 at 2:04 AM Chris Johns  wrote:
>
> On 21/7/21 3:37 pm, Sebastian Huber wrote:
> > Hello Chris,
> >
> > thanks, this is a nice improvement.
>
> It helps find the corruption with a watch point.
>
> > On 21/07/2021 07:17, chr...@rtems.org wrote:
> >> --- a/bsps/shared/start/bspfatal-default.c
> >> +++ b/bsps/shared/start/bspfatal-default.c
> >> @@ -22,15 +22,24 @@ void bsp_fatal_extension(
> >>   {
> >> #if BSP_VERBOSE_FATAL_EXTENSION
> >>   Thread_Control *executing;
> >> +const char* TYPE = "*** FATAL ***\n";
> >> +const char* type = "fatal";
> >> +
> >> +if ( source == RTEMS_FATAL_SOURCE_EXIT ) {
> >> +  TYPE = "";
> >
> > It would be good to still have a unique pattern which starts the fatal 
> > extension
> > message.  The "***" is also used for the test begin/end marker. What about 
> > "***
> > SYSTEM TERMINATED ***"?
>
> I considered this but I was concerned about the difference not being clear.
> Maybe I overstepped. The patch gives us:
>
> exit source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> exit code: 0 (0x)
> RTEMS version: 6.0.0.87609bacd323eef1f3f4d6620ce42e7e5309ad10
> RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
> 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
> executing thread ID: 0x08a010001
> executing thread name: UI1
>
> and with the banner text:
>
> *** EXIT ***
> exit source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> exit code: 0 (0x)
> RTEMS version: 6.0.0.87609bacd323eef1f3f4d6620ce42e7e5309ad10
> RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
> 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
> executing thread ID: 0x08a010001
> executing thread name: UI1
>
> It is easy to bend any direction here so maybe we wait for Joel to comment
> before I make a v2 patch.

This still looks scary when it is a normal exit(0) which is a big
issue with the current output. If exit source == 5 and exit code == 0,
can those two lines be a friendly, feel good message instead of something
you have to understand to know it was a normal exit.

When you run a test, will we end up with something like this for a normal
exit?

*** END OF TEST ...
*** EXIT ***

And just "*** EXIT ***" when there is no END OF TEST message?

How about something as simple as NORMAL or ABNORMAL EXIT in your
new line? And if normal, drop the exit source and code lines.

I still have flashbacks to the first time I saw this output every time I
show someone a test running. It took me a few minutes to realize
it was OK. And it still often takes a second glance to say "all ok."
If it can be easier to see "good," that would be a user facing improvement IMO

--joel
>
> Chris
> ___
> 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] build: Add the BSP family to the enable set

[Joel Sherrill]

On Wed, Jul 21, 2021, 5:49 PM Chris Johns  wrote:

> On 22/7/21 8:35 am, Joel Sherrill wrote:
> > On Wed, Jul 21, 2021 at 2:10 PM Sebastian Huber
> >  wrote:
> >>
> >> On 21/07/2021 21:05, Gedare Bloom wrote:
> > The problem is that one BSP which supports SMP "riscv/griscv" is
> identical to
> > the family "riscv/griscv" which contains BSPs which do not support
> SMP
> > ("riscv/grv32i" and riscv/grv32im").
>  Hmm, tricky. Can the BSPs that do not support SMP disable SMP in the
> BSP
>  specific config, ie override/specialise in the BSP?
> 
> >>> Or, can we avoid having duplication between BSP names and family names?
> >>
> >> Yes, good idea. We could use a "family/" prefix for example
> >> ("family//").
>
> Great idea.
>
> > Ideally we would never have a family and BSP variant have the same name.
> > But that rule is violated multiple times now.
>
> Yeap.
>
> > I am not sure where your triple is intended to be used but we have used
> > the pattern arch/BSP which is really / as the
> > full name of BSPs.
> >
> > If we want to step that further, we could do something similar to the
> > GNU target triple where the middle component is a rarely used vendor.
> > //.
>
> I think we are to late for this because the spec file format follows what
> I did
> in the eco-system and I would prefer we maintained a single unified way of
> doing
> this than changing it.
>
> > In recent history, there was an issue of BSP variant names needing to
> > be unique across all architectures. This may also need to apply to bsp
> > family names.
>
> What about "bsps/". This means you have:
>
> powerpc/mvme2307
> bsps/motorola_powerpc
>

Is the first line is our BSP formal naming pattern and the second is how
families are named, that should be ok.

Rules for uniqueness apply.



> It is simple and clean.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsp: Remove fatal from exit(0). Add extended heap error output

[Chris Johns]

On 22/7/21 8:45 am, Joel Sherrill wrote:
> On Wed, Jul 21, 2021 at 2:04 AM Chris Johns  wrote:
>>
>> On 21/7/21 3:37 pm, Sebastian Huber wrote:
>>> Hello Chris,
>>>
>>> thanks, this is a nice improvement.
>>
>> It helps find the corruption with a watch point.
>>
>>> On 21/07/2021 07:17, chr...@rtems.org wrote:
 --- a/bsps/shared/start/bspfatal-default.c
 +++ b/bsps/shared/start/bspfatal-default.c
 @@ -22,15 +22,24 @@ void bsp_fatal_extension(
   {
 #if BSP_VERBOSE_FATAL_EXTENSION
   Thread_Control *executing;
 +const char* TYPE = "*** FATAL ***\n";
 +const char* type = "fatal";
 +
 +if ( source == RTEMS_FATAL_SOURCE_EXIT ) {
 +  TYPE = "";
>>>
>>> It would be good to still have a unique pattern which starts the fatal 
>>> extension
>>> message.  The "***" is also used for the test begin/end marker. What about 
>>> "***
>>> SYSTEM TERMINATED ***"?
>>
>> I considered this but I was concerned about the difference not being clear.
>> Maybe I overstepped. The patch gives us:
>>
>> exit source: 5 (RTEMS_FATAL_SOURCE_EXIT)
>> exit code: 0 (0x)
>> RTEMS version: 6.0.0.87609bacd323eef1f3f4d6620ce42e7e5309ad10
>> RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
>> 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
>> executing thread ID: 0x08a010001
>> executing thread name: UI1
>>
>> and with the banner text:
>>
>> *** EXIT ***
>> exit source: 5 (RTEMS_FATAL_SOURCE_EXIT)
>> exit code: 0 (0x)
>> RTEMS version: 6.0.0.87609bacd323eef1f3f4d6620ce42e7e5309ad10
>> RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
>> 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
>> executing thread ID: 0x08a010001
>> executing thread name: UI1
>>
>> It is easy to bend any direction here so maybe we wait for Joel to comment
>> before I make a v2 patch.
> 
> This still looks scary when it is a normal exit(0) which is a big
> issue with the current output. If exit source == 5 and exit code == 0,
> can those two lines be a friendly, feel good message instead of something
> you have to understand to know it was a normal exit.
> 
> When you run a test, will we end up with something like this for a normal
> exit?
> 
> *** END OF TEST ...
> *** EXIT ***
> 
> And just "*** EXIT ***" when there is no END OF TEST message?

The end of test and the fatal message are no related so I am not sure how you
could do this. You only the values passed to the fatal error extension handler.

> How about something as simple as NORMAL or ABNORMAL EXIT in your
> new line? And if normal, drop the exit source and code lines.
> 
> I still have flashbacks to the first time I saw this output every time I
> show someone a test running. It took me a few minutes to realize
> it was OK. And it still often takes a second glance to say "all ok."
> If it can be easier to see "good," that would be a user facing improvement IMO

Yes it trips me up often as I search for the code to see if it is a real fatal
error and I also miss some real errors. How about:

RTEMS Shutdown
RTEMS version: 6.0.0.87609bacd323eef1f3f4d6620ce42e7e5309ad10
RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
executing thread ID: 0x08a010001
executing thread name: UI1

and if `exit(1)` is called:

*** EXIT ERROR ***
exit code: 1 (0x0001)
RTEMS version: 6.0.0.87609bacd323eef1f3f4d6620ce42e7e5309ad10
RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
executing thread ID: 0x08a010001
executing thread name: UI1

?

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

Re: [PATCH] linker_set.h: Add alignof implementation for when not C11 or C++11

[Chris Johns]

On 22/7/21 7:55 am, Joel Sherrill wrote:
> On Wed, Jul 21, 2021, 4:31 PM Gedare Bloom  > wrote:
> 
> This seems alright to me. At least, it should get some complaints
> quickly if it doesn't work :)
> 
> The old version should have gotten complaints but didn't. Probably indicates
> people are not being careful about specifying the language version they want 
> to
> use and just taking the GCC default which periodically changes. 

Is this a problem on 5-freebsd-12?

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

Re: [PATCH] build: Add the BSP family to the enable set

[Chris Johns]

On 22/7/21 8:55 am, Joel Sherrill wrote:
> On Wed, Jul 21, 2021, 5:49 PM Chris Johns  > wrote:
> 
> On 22/7/21 8:35 am, Joel Sherrill wrote:
> > On Wed, Jul 21, 2021 at 2:10 PM Sebastian Huber
> >  > wrote:
> >>
> >> On 21/07/2021 21:05, Gedare Bloom wrote:
> > The problem is that one BSP which supports SMP "riscv/griscv" is
> identical to
> > the family "riscv/griscv" which contains BSPs which do not support 
> SMP
> > ("riscv/grv32i" and riscv/grv32im").
>  Hmm, tricky. Can the BSPs that do not support SMP disable SMP in the 
> BSP
>  specific config, ie override/specialise in the BSP?
> 
> >>> Or, can we avoid having duplication between BSP names and family 
> names?
> >>
> >> Yes, good idea. We could use a "family/" prefix for example
> >> ("family//").
> 
> Great idea.
> 
> > Ideally we would never have a family and BSP variant have the same name.
> > But that rule is violated multiple times now.
> 
> Yeap.
> 
> > I am not sure where your triple is intended to be used but we have used
> > the pattern arch/BSP which is really / as the
> > full name of BSPs.
> >
> > If we want to step that further, we could do something similar to the
> > GNU target triple where the middle component is a rarely used vendor.
> > //.
> 
> I think we are to late for this because the spec file format follows what 
> I did
> in the eco-system and I would prefer we maintained a single unified way 
> of doing
> this than changing it.
> 
> > In recent history, there was an issue of BSP variant names needing to
> > be unique across all architectures. This may also need to apply to bsp
> > family names.
> 
> What about "bsps/". This means you have:
> 
> powerpc/mvme2307
> bsps/motorola_powerpc
> 
> Is the first line is our BSP formal naming pattern and the second is how
> families are named, that should be ok.

It is as you state. In a formal sense it is:

BSP: /
BSP FAMILY:  bsps

This format and approach does not break existing eco-system code that is set up
to parse a single `/` into two parts, the arch and bsp. A check of the arch
component for `bsps` can raise an error, ie unknown arch, or be extended to
handle a BSP family.

> Rules for uniqueness apply.

Yes.

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

Re: [PATCH] linker_set.h: Add alignof implementation for when not C11 or C++11

[Joel Sherrill]

On Wed, Jul 21, 2021, 4:31 PM Gedare Bloom  wrote:

> This seems alright to me. At least, it should get some complaints
> quickly if it doesn't work :)
>

The old version should have gotten complaints but didn't. Probably
indicates people are not being careful about specifying the language
version they want to use and just taking the GCC default which periodically
changes.

--joel

>
> On Tue, Jul 20, 2021 at 3:04 PM Joel Sherrill  wrote:
> >
> > The default implementation was completely broken. Use the GCC specific
> > __alignof__ if compiling for C99 or C++03. If not C++11, C11, or
> > GCC, then it is an error.
> > ---
> >  freebsd/sys/sys/linker_set.h | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/freebsd/sys/sys/linker_set.h b/freebsd/sys/sys/linker_set.h
> > index baa5ae4..9af5307 100755
> > --- a/freebsd/sys/sys/linker_set.h
> > +++ b/freebsd/sys/sys/linker_set.h
> > @@ -73,8 +73,10 @@
> >#define RTEMS_BSD_ALIGNOF( _type_name ) alignof( _type_name )
> >  #elif __STDC_VERSION__ >= 201112L
> >#define RTEMS_BSD_ALIGNOF( _type_name ) _Alignof( _type_name )
> > +#elif defined(__GNUC__)
> > +  #define RTEMS_BSD_ALIGNOF( _type_name ) __alignof__( _type_name )
> >  #else
> > -  #define RTEMS_BSD_ALIGNOF( _type_name ) sizeof( _type_name )
> > +  #error "FIX ME! Implement RTEMS_BSD_ALIGNOF() for this environment"
> >  #endif
> >
> >  #define RTEMS_BSD_SET_ALIGN( type )\
> > --
> > 1.8.3.1
> >
> > ___
> > 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] build: Add the BSP family to the enable set

[Joel Sherrill]

On Wed, Jul 21, 2021 at 2:10 PM Sebastian Huber
 wrote:
>
> On 21/07/2021 21:05, Gedare Bloom wrote:
> >>> The problem is that one BSP which supports SMP "riscv/griscv" is 
> >>> identical to
> >>> the family "riscv/griscv" which contains BSPs which do not support SMP
> >>> ("riscv/grv32i" and riscv/grv32im").
> >> Hmm, tricky. Can the BSPs that do not support SMP disable SMP in the BSP
> >> specific config, ie override/specialise in the BSP?
> >>
> > Or, can we avoid having duplication between BSP names and family names?
>
> Yes, good idea. We could use a "family/" prefix for example
> ("family//").

Ideally we would never have a family and BSP variant have the same name.
But that rule is violated multiple times now.

I am not sure where your triple is intended to be used but we have used
the pattern arch/BSP which is really / as the
full name of BSPs.

If we want to step that further, we could do something similar to the
GNU target triple where the middle component is a rarely used vendor.
//.

In recent history, there was an issue of BSP variant names needing to
be unique across all architectures. This may also need to apply to bsp
family names.

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add the BSP family to the enable set

[Chris Johns]

On 22/7/21 8:35 am, Joel Sherrill wrote:
> On Wed, Jul 21, 2021 at 2:10 PM Sebastian Huber
>  wrote:
>>
>> On 21/07/2021 21:05, Gedare Bloom wrote:
> The problem is that one BSP which supports SMP "riscv/griscv" is 
> identical to
> the family "riscv/griscv" which contains BSPs which do not support SMP
> ("riscv/grv32i" and riscv/grv32im").
 Hmm, tricky. Can the BSPs that do not support SMP disable SMP in the BSP
 specific config, ie override/specialise in the BSP?

>>> Or, can we avoid having duplication between BSP names and family names?
>>
>> Yes, good idea. We could use a "family/" prefix for example
>> ("family//").

Great idea.

> Ideally we would never have a family and BSP variant have the same name.
> But that rule is violated multiple times now.

Yeap.

> I am not sure where your triple is intended to be used but we have used
> the pattern arch/BSP which is really / as the
> full name of BSPs.
> 
> If we want to step that further, we could do something similar to the
> GNU target triple where the middle component is a rarely used vendor.
> //.

I think we are to late for this because the spec file format follows what I did
in the eco-system and I would prefer we maintained a single unified way of doing
this than changing it.

> In recent history, there was an issue of BSP variant names needing to
> be unique across all architectures. This may also need to apply to bsp
> family names.

What about "bsps/". This means you have:

powerpc/mvme2307
bsps/motorola_powerpc

It is simple and clean.

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

Re: [PATCH] build: Add "family/" prefix to BSP familiy enable

[Chris Johns]

On 22/7/21 5:22 am, Sebastian Huber wrote:
> BSP family and BSP variant names may be equal.  This prefix avoids
> ambiguity in the enabled-by expressions.
> ---
>  wscript | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/wscript b/wscript
> index f27dba6831..b7a0412150 100755
> --- a/wscript
> +++ b/wscript
> @@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, 
> top_group, variant):
>  conf.env["ENABLE"] = [
>  get_compiler(conf, cp, variant),
>  arch,
> -arch_family,
> +"family/" + arch_family,

   "bsps/" + arch_family,

... as discussed in the other thread? If you are happy with the change as shown
please push.

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

Re: [PATCH 04/41] rtems: Add rtems_interrupt_cause_on()

[Gedare Bloom]

On Wed, Jul 21, 2021 at 11:46 AM Gedare Bloom  wrote:
>
> On Wed, Jul 21, 2021 at 11:43 AM Gedare Bloom  wrote:
> >
> > Before we bake this into the API forever, I want to ask if "cause" is
> > the right word to use here? Often, "interrupt cause" is thought of as
> > a noun to mean what caused the interrupt, while the verb is usually
> > "raise" or post, trigger, etc. Because "cause" is both a noun and a
> > verb that mean something in this context, it may be better to use a
> > different verb. English is pretty much terrible.
> >
> > I don't have a major problem with sticking to "cause" but thought I'd
> > bring this up.
> >
> > On Mon, Jul 12, 2021 at 6:50 AM Sebastian Huber
> >  wrote:
> > >
> > > Document the currently not implemented rtems_interrupt_cause() and
> > > rtems_interrupt_clear().
> > >
> > > Update #3269.
> > > ---
> > >  cpukit/include/rtems/rtems/intr.h | 162 +++---
> > >  1 file changed, 125 insertions(+), 37 deletions(-)
> > >
> > > diff --git a/cpukit/include/rtems/rtems/intr.h 
> > > b/cpukit/include/rtems/rtems/intr.h
> > > index 178cf342df..a8b1b892b5 100644
> > > --- a/cpukit/include/rtems/rtems/intr.h
> > > +++ b/cpukit/include/rtems/rtems/intr.h
> > > @@ -54,6 +54,7 @@
> > >  #ifndef _RTEMS_RTEMS_INTR_H
> > >  #define _RTEMS_RTEMS_INTR_H
> > >
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -99,7 +100,7 @@ typedef ISR_Handler rtems_isr;
> > >   * @ingroup RTEMSAPIClassicIntr
> > >   *
> > >   * @brief Interrupt service routines installed by 
> > > rtems_interrupt_catch() shall
> > > - *   have this function pointer type.
> > > + *   have this type.
> > >   */
> > >  #if CPU_SIMPLE_VECTORED_INTERRUPTS == TRUE
> > >typedef ISR_Handler_entry rtems_isr_entry;
> > > @@ -502,42 +503,6 @@ rtems_status_code rtems_interrupt_catch(
> > >   */
> > >  #define rtems_interrupt_is_in_progress() _ISR_Is_in_progress()
> > >
> > > -/* Generated from spec:/rtems/intr/if/cause */
> > > -
> > > -/**
> > > - * @ingroup RTEMSAPIClassicIntr
> > > - *
> > > - * @brief Causes the interrupt.
> > > - *
> > > - * @param _vector is the vector number of the interrupt to cause.
> > > - *
> > > - * @par Constraints
> > > - * @parblock
> > > - * The following constraints apply to this directive:
> > > - *
> > > - * * The directive is not implemented.
> > > - * @endparblock
> > > - */
> > > -#define rtems_interrupt_cause( _vector ) do { } while ( 0 )
> > > -
> > > -/* Generated from spec:/rtems/intr/if/clear */
> > > -
> > > -/**
> > > - * @ingroup RTEMSAPIClassicIntr
> > > - *
> > > - * @brief Clears the interrupt.
> > > - *
> > > - * @param _vector is the vector number of the interrupt to clear.
> > > - *
> > > - * @par Constraints
> > > - * @parblock
> > > - * The following constraints apply to this directive:
> > > - *
> > > - * * The directive is not implemented.
> > > - * @endparblock
> > > - */
> > > -#define rtems_interrupt_clear( _vector ) do { } while ( 0 )
> > > -
> > >  /* Generated from spec:/rtems/intr/if/lock-initialize */
> > >
> > >  /**
> > > @@ -909,6 +874,129 @@ rtems_status_code rtems_interrupt_catch(
> > >  #define RTEMS_INTERRUPT_LOCK_REFERENCE( _designator, _target ) \
> > >ISR_LOCK_REFERENCE( _designator, _target )
> > >
> > > +/* Generated from spec:/rtems/intr/if/cause */
> > > +
> > > +/**
> > > + * @ingroup RTEMSAPIClassicIntr
> > > + *
> > > + * @brief Causes the interrupt vector.
> > > + *
> > > + * @param vector is the number of the interrupt vector to cause.
> > > + *
> > > + * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
> > > + *
> > > + * @retval ::RTEMS_INVALID_ID There was no interrupt vector associated 
> > > with the
> > > + *   number specified by ``vector``.
> > > + *
> > > + * @retval ::RTEMS_UNSATISFIED The request to cause the interrupt vector 
> > > has
> > > + *   not been satisfied.
> > > + *
> > > + * @par Notes
> > > + * The rtems_interrupt_get_attributes() directive may be used to check 
> > > if an
> > > + * interrupt vector can be caused.
> > > + *
> > > + * @par Constraints
> > > + * @parblock
> > > + * The following constraints apply to this directive:
> > > + *
> > > + * * The directive may be called from within interrupt context.
> > > + *
> > > + * * The directive may be called from within device driver initialization
> > > + *   context.
> > > + *
> > > + * * The directive may be called from within task context.
> > > + *
> > > + * * The directive will not cause the calling task to be preempted.
> > > + * @endparblock
> > > + */
> > > +rtems_status_code rtems_interrupt_cause( rtems_vector_number vector );
> > > +
> > > +/* Generated from spec:/rtems/intr/if/cause-on */
> > > +
> > > +/**
> > > + * @ingroup RTEMSAPIClassicIntr
> > > + *
> > > + * @brief Causes the interrupt vector on the processor.
> > > + *
> > > + * @param vector is the number of the interrupt vector to cause.
> > > + *
> > > + * @param cpu_index is the index of the target processor of the interrupt
> > > 

Re: [PATCH 23/41] bsps/irq: Add bsp_interrupt_check_and_lock()

[Gedare Bloom]

On Mon, Jul 12, 2021 at 6:51 AM Sebastian Huber
 wrote:
>
> Return RTEMS_INCORRECT_STATE instead of RTEMS_INCORRECT_STATE in case the
Second RTEMS_INCORRECT_STATE should be RTEMS_INTERNAL_ERROR

> interrupt support is not initialized.  This is similar to
> rtems_timer_server_fire_after() for example.
>
> Update #3269.
> ---
>  bsps/include/bsp/irq-generic.h| 25 +++
>  bsps/shared/irq/irq-generic.c | 60 ---
>  bsps/shared/irq/irq-handler-iterate.c | 51 +++
>  3 files changed, 75 insertions(+), 61 deletions(-)
>
> diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h
> index b553ac30bf..9babc4cfb5 100644
> --- a/bsps/include/bsp/irq-generic.h
> +++ b/bsps/include/bsp/irq-generic.h
> @@ -434,6 +434,31 @@ void bsp_interrupt_lock(void);
>  /* For internal use only */
>  void bsp_interrupt_unlock(void);
>
> +/**
> + * @brief Checks the vector and routine.  When the checks were successful, 
> the
> + *   interrupt support lock will be obtained.
> + *
> + * @param vector is the interrupt vector number to check.
> + *
> + * @param routine is the routine to check.
> + *
> + * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
> + *
> + * @retval ::RTEMS_INCORRECT_STATE The interrupt support was not initialized.
> + *
> + * @retval ::RTEMS_CALLED_FROM_ISR The function was called from within
> + *   interrupt context.
> + *
> + * @retval ::RTEMS_INVALID_ADDRESS The ``routine`` parameter was NULL.
> + *
> + * @retval ::RTEMS_INVALID_ID There was no interrupt vector associated with 
> the
> + *   number specified by ``vector``.
> + */
> +rtems_status_code bsp_interrupt_check_and_lock(
> +  rtems_vector_number vector,
> +  rtems_interrupt_handler handler
> +);
> +
>  /**
>   * @brief This table contains a bit map which indicates if an entry is unique
>   *   or shared.
> diff --git a/bsps/shared/irq/irq-generic.c b/bsps/shared/irq/irq-generic.c
> index a7e8c1163f..59963182ab 100644
> --- a/bsps/shared/irq/irq-generic.c
> +++ b/bsps/shared/irq/irq-generic.c
> @@ -122,6 +122,32 @@ static inline bool bsp_interrupt_allocate_handler_index(
>#endif
>  }
>
> +rtems_status_code bsp_interrupt_check_and_lock(
> +  rtems_vector_number vector,
> +  rtems_interrupt_handler handler
> +)
> +{
> +  if ( !bsp_interrupt_is_initialized() ) {
> +return RTEMS_INCORRECT_STATE;
> +  }
> +
> +  if ( handler == NULL ) {
> +return RTEMS_INVALID_ADDRESS;
> +  }
> +
> +  if ( !bsp_interrupt_is_valid_vector( vector ) ) {
> +return RTEMS_INVALID_ID;
> +  }
> +
> +  if ( rtems_interrupt_is_in_progress() ) {
> +return RTEMS_CALLED_FROM_ISR;
> +  }
> +
> +  bsp_interrupt_lock();
> +
> +  return RTEMS_SUCCESSFUL;
> +}
> +
>  void bsp_interrupt_initialize(void)
>  {
>rtems_status_code sc = RTEMS_SUCCESSFUL;
> @@ -162,25 +188,18 @@ static rtems_status_code bsp_interrupt_handler_install(
>void *arg
>  )
>  {
> +  rtems_status_code sc;
>rtems_interrupt_level level;
>rtems_vector_number index = 0;
>rtems_interrupt_entry *head = NULL;
>bool enable_vector = false;
>bool replace = RTEMS_INTERRUPT_IS_REPLACE(options);
>
> -  /* Check parameters and system state */
> -  if (!bsp_interrupt_is_initialized()) {
> -return RTEMS_INTERNAL_ERROR;
> -  } else if (!bsp_interrupt_is_valid_vector(vector)) {
> -return RTEMS_INVALID_ID;
> -  } else if (handler == NULL) {
> -return RTEMS_INVALID_ADDRESS;
> -  } else if (rtems_interrupt_is_in_progress()) {
> -return RTEMS_CALLED_FROM_ISR;
> -  }
> +  sc = bsp_interrupt_check_and_lock( vector, handler );
>
> -  /* Lock */
> -  bsp_interrupt_lock();
> +  if ( sc != RTEMS_SUCCESSFUL ) {
> +return sc;
> +  }
>
>/* Get handler table index */
>index = bsp_interrupt_handler_index(vector);
> @@ -325,6 +344,7 @@ static rtems_status_code bsp_interrupt_handler_remove(
>void *arg
>  )
>  {
> +  rtems_status_code sc;
>rtems_interrupt_level level;
>rtems_vector_number index = 0;
>rtems_interrupt_entry *head = NULL;
> @@ -332,19 +352,11 @@ static rtems_status_code bsp_interrupt_handler_remove(
>rtems_interrupt_entry *previous = NULL;
>rtems_interrupt_entry *match = NULL;
>
> -  /* Check parameters and system state */
> -  if (!bsp_interrupt_is_initialized()) {
> -return RTEMS_INTERNAL_ERROR;
> -  } else if (!bsp_interrupt_is_valid_vector(vector)) {
> -return RTEMS_INVALID_ID;
> -  } else if (handler == NULL) {
> -return RTEMS_INVALID_ADDRESS;
> -  } else if (rtems_interrupt_is_in_progress()) {
> -return RTEMS_CALLED_FROM_ISR;
> -  }
> +  sc = bsp_interrupt_check_and_lock( vector, handler );
>
> -  /* Lock */
> -  bsp_interrupt_lock();
> +  if ( sc != RTEMS_SUCCESSFUL ) {
> +return sc;
> +  }
>
>/* Get handler table index */
>index = bsp_interrupt_handler_index(vector);
> diff --git a/bsps/shared/irq/irq-handler-iterate.c 
> b/bsps/shared/irq/irq-handler-iterate.c
> index 3c642b075e..385cb8db2d 100644
>