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

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

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

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

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

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

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

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

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

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 >> @@

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Building a library for use with RTEMS via CMake

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

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

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

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

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

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

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

Re: [PATCH 05/41] rtems: Generate

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

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

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 >

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

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 +++ >

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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 > +++

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

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

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

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 >

Re: [PATCH 05/41] rtems: Generate

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

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

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"

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

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

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

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 |

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

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

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

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

Re: [PATCH 05/41] rtems: Generate

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

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

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

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

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

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

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,

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

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

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

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. +

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

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 ++- > >>

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

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

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

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

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

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

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

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 >

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

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,

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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