Re: [PATCH 2/3] user: Add A53 Qemu run instructions

[Gedare Bloom]

On Fri, Dec 11, 2020 at 11:58 AM Kinsey Moore 
wrote:

> *From:* Gedare Bloom 
> *Sent:* Friday, December 11, 2020 07:41
> *To:* Kinsey Moore 
> *Cc:* devel@rtems.org
> *Subject:* Re: [PATCH 2/3] user: Add A53 Qemu run instructions
>
>
>
>
>
>
>
> On Tue, Dec 8, 2020 at 11:03 AM Kinsey Moore 
> wrote:
>
> ---
>  user/bsps/aarch64/a53.rst | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/user/bsps/aarch64/a53.rst b/user/bsps/aarch64/a53.rst
> index 73735b1..e3a89f8 100644
> --- a/user/bsps/aarch64/a53.rst
> +++ b/user/bsps/aarch64/a53.rst
> @@ -25,3 +25,10 @@ Console Driver
>  --
>
>  The console driver supports the default Qemu emulated ARM PL011 PrimeCell
> UART.
> +
> +Running Executables
> +---
> +
> +Executables generated by these BSPs can be run using the following
> command::
> +
> +qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio -machine
> virt,gic_version=3 -cpu cortex-a53 -m 4096 -kernel example.exe
>
>
>
> Check the line break on PDF, maybe typeset an explicit line break \
>
>
>
> I’ll break this one as well as the one in the ZynqMP BSP docs. Did you
> want to see another patchset or is it otherwise good to commit?
>
>
>

looks good otherwise


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

RE: [PATCH 1/2] tm27: Use generic cpu index accessor

[Kinsey Moore]

-Original Message-
From: Sebastian Huber  
Sent: Friday, December 11, 2020 13:00
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH 1/2] tm27: Use generic cpu index accessor

> On 11/12/2020 16:09, Kinsey Moore wrote:
>
>> Unfortunately, that's the only API currently available to get that 
>> information easily on both architectures. The base function that is wrapped 
>> (_CPU_SMP_Get_current_processor) could be provided outside the RTEMS_SMP 
>> ifdef block and that could be used instead since this is specific to 
>> ARM/AArch64. Would that be acceptable?
>
> If _CPU_SMP_Get_current_processor() returns != 0 if 
> CONFIGURE_MAXIMUM_PROCESSORS == 1, then this is undefined behaviour, 
> since this value is used to index _Per_CPU_Information.
>
> I think for now, the patch is fine.

I'll commit this patch as is and the other with the alternate cast.

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

Re: CMake support

[Robin Müller]

I added the suggestions by Chris Johns now and performed some more tests
(for example disabling the default compiler checks, custom checks are
required for RTEMS).

I used RTEMS_PREFIX instead of PREFIX because PREFIX appears to be a
reserved name in CMake, and RTEMS_PREFIX is also a little bit more explicit.
It is now possible to set a separate BSP path by supplying RTEMS_PATH and a
different tools path by supplying RTEMS_TOOLS like suggested.

Maybe CMake can also read the .pc pkgfiles in some way to determine
compiler/linker flags automatically, at least Kitware has a module like
this
https://github.com/Kitware/CMake/blob/master/Modules/FindPkgConfig.cmake .

Kind Regards
Robin

On Fri, 11 Dec 2020 at 11:14, Robin Müller 
wrote:

> Hi,
>
> There seems to be positive feedback, thanks for that.
>
> I can adapt the naming to be more consistent with your system.
> My system is currently assuming that the RTEMS tools and the BSP are both
> located at RTEMS_INST
> I guess the first command:
>
> cmake -DPREFIX=/install-point -DRTEMS_BSP=arm/stm32h7
>
> Would have the purpose to install the BSP itself? Right now, I also used
> the tools path to autodetermine the RTEMS version
> if the version is not supplied manually.cmake by extracting the last
> number in the supplied RTEMS_INST path.
>
> I have not really thought about the install process yet, I simply built
> the binary in a separate folder out of source like normally done in CMake.
> But this should generally be possible, CMake has an install command as
> well and the install location can be set using CMAKE_INSTALL_PREFIX
>
> Is it possible to get the pkgconfig files without building the BSPs? That
> would be good so more hardware configurations can be added without having
> to build every BSP.
>
> Kind Regards
> Robin
>
> On Fri, 11 Dec 2020 at 10:59, Stanislav Pankevich 
> wrote:
>
>> Hi all,
>>
>> > I was wondering whether CMake support or an example is available or
>> will be added in the future. We are using a framework which has different
>> abstraction layers for OSes like (embedded) Linux, RTEMS and FreeRTOS, but
>> we would like to use the same build system to build applications and right
>> now CMake is our favourite because other tools like the Catch2 test
>> framework are also built with CMake and there is a lot more
>> documentation available for CMake.
>>
>> I would like to share our (PTS GmbH, Berlin) experience of using CMake
>> with RTEMS. Our case is similar to that of Robin Müller's and our own
>> software is all CMake-based. An additional advantage for using CMake for us
>> is that the NASA cFS framework has recently switched to CMake so it is much
>> easier to integrate it into the existing CMake tree. Another integration
>> exercise that we had done before was to build RTEMS and DLR Outpost with
>> CMake and that was also quite straightforward in spite of the fact the DLR
>> Outpost didn't have a CMake layer.
>>
>> ~1 year ago we have captured all the RTEMS compilation and linking
>> commands done by Autoconf for building the ARM-based BSP and converted them
>> into CMakeLists.txt files. At that time, we didn't know how exactly the
>> existing build system worked, so we were very careful and created many
>> CMakeLists files, one for a folder (example: cpukit/libmisc/cpuuse or our
>> own BSP folder). Our setup in the end is not 3 files but 60 files but the
>> idea is the same: configs are collected in a few files, the rest are simply
>> assigning source files to object/library targets. No changes are made to
>> RTEMS source or build files. Instead, we keep all CMake scripts in a
>> separate folder called: rtems-cmake-integration.
>>
>> One of the problems we see with this approach is updating to newer
>> versions of RTEMS. If the CMake files do not co-exist with the RTEMS
>> development tree, then it might be a manual exercise every time to make
>> sure that the CMake integration layer always reflects what the developers
>> of RTEMS intend it to be. Having this said, our 1-year-old CMake setup has
>> been very stable so far, so we might as well stick with it for the time
>> being.
>>
>> Having this said, I would like to avoid pushing the CMake-way of doing
>> things as a better way. Instead, I could contribute feedback to Robin's
>> work here: https://github.com/rmspacefish/rtems-cmake. For example, I
>> could do the exercise of using his Just 3 files to see if our embedded
>> target would compile and run. No hard promises about the time frames though
>> until the Christmas holidays :)
>>
>> Thank you for your attention.
>>
>> On Fri, Dec 11, 2020 at 1:15 AM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Thu, Dec 10, 2020 at 5:58 PM Chris Johns  wrote:
>>>
 On 11/12/20 8:51 am, Robin Müller wrote:
 > Hello,
 >
 > I created a repository on github for the first version of what a
 CMake support
 > for RTEMS might look like:
 >
 > https://github.com/rmspacefish/rtems-cmake
 > 

Re: [PATCH 1/2] tm27: Use generic cpu index accessor

[Sebastian Huber]

On 11/12/2020 16:09, Kinsey Moore wrote:


-Original Message-
From: Sebastian Huber  
Sent: Thursday, December 10, 2020 23:48

To: Kinsey Moore;devel@rtems.org
Subject: Re: [PATCH 1/2] tm27: Use generic cpu index accessor


On 10/12/2020 21:42, Kinsey Moore wrote:

The arm_cp15 function for accessing the current CPU index is specific
to ARMv7 while this header is used for ARMv8 as well. Instead, use a
generic accessor that is part of the standard CPU API.

I am fine with this fix, however, this is basically now the same
approach as in my v2 patch:

https://lists.rtems.org/pipermail/devel/2020-December/063693.html

Since the tm27 test is configured to use only one CPU, the current
processor is always 0.

Unfortunately, that's the only API currently available to get that information 
easily on both architectures. The base function that is wrapped 
(_CPU_SMP_Get_current_processor) could be provided outside the RTEMS_SMP ifdef 
block and that could be used instead since this is specific to ARM/AArch64. 
Would that be acceptable?


If _CPU_SMP_Get_current_processor() returns != 0 if 
CONFIGURE_MAXIMUM_PROCESSORS == 1, then this is undefined behaviour, 
since this value is used to index _Per_CPU_Information.


I think for now, the patch is fine.

What we have is an API mismatch between the logical processor index and 
the MPIDR register. Currently, a one-to-one mapping is assumed. For a 
proper support of clustered systems we may need a more complex mapping 
(for example a four core system consisting of a cluster (aff1: 0 or 1) 
of two cores each (aff0: 0 or 1)).


--
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 2/3] user: Add A53 Qemu run instructions

[Kinsey Moore]

From: Gedare Bloom 
Sent: Friday, December 11, 2020 07:41
To: Kinsey Moore 
Cc: devel@rtems.org
Subject: Re: [PATCH 2/3] user: Add A53 Qemu run instructions



On Tue, Dec 8, 2020 at 11:03 AM Kinsey Moore 
mailto:kinsey.mo...@oarcorp.com>> wrote:
---
 user/bsps/aarch64/a53.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/user/bsps/aarch64/a53.rst b/user/bsps/aarch64/a53.rst
index 73735b1..e3a89f8 100644
--- a/user/bsps/aarch64/a53.rst
+++ b/user/bsps/aarch64/a53.rst
@@ -25,3 +25,10 @@ Console Driver
 --

 The console driver supports the default Qemu emulated ARM PL011 PrimeCell UART.
+
+Running Executables
+---
+
+Executables generated by these BSPs can be run using the following command::
+
+qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio -machine 
virt,gic_version=3 -cpu cortex-a53 -m 4096 -kernel example.exe

Check the line break on PDF, maybe typeset an explicit line break \

I’ll break this one as well as the one in the ZynqMP BSP docs. Did you want to 
see another patchset or is it otherwise good to commit?

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

Re: Build FreeBSD: FAILED 6/rtems-arm on x86_64-freebsd12.1 (arm-rtems6-gcc-c25f7ea-newlib-21ec498-x86_64-freebsd12.1-1)

[Sebastian Huber]

On 11/12/2020 18:22, sebastian.hu...@embedded-brains.de wrote:

/usr/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-c25f7ea-newlib-21ec498-x86_64-freebsd12.1-1/build/./gcc/xgcc 
-B/usr/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-c25f7ea-newlib-21ec498-x86_64-freebsd12.1-1/build/./gcc/  -xc -nostdinc /dev/null -S -o /dev/null -fself-test=../../gnu-mirror-gcc-c25f7ea/gcc/testsuite/selftests
/usr/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-c25f7ea-newlib-21ec498-x86_64-freebsd12.1-1/build/./gcc/xgcc 
-B/usr/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-c25f7ea-newlib-21ec498-x86_64-freebsd12.1-1/build/./gcc/  -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=../../gnu-mirror-gcc-c25f7ea/gcc/testsuite/selftests

ld-elf.so.1: Shared object "libgmp.so.10" not found, required by "cc1"
ld-elf.so.1: Shared object "libgmp.so.10" not found, required by "cc1plus"

It seems that adding GMP to the GDB build breaks the GCC build.

--
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 v2] eng: Requirements counting shall start at zero

[Joel Sherrill]

On Fri, Dec 11, 2020 at 10:38 AM Gedare Bloom  wrote:

>
>
> On Fri, Dec 11, 2020 at 9:12 AM Frank Kühndel <
> frank.kuehn...@embedded-brains.de> wrote:
>
>> Hello Gedare,
>>
>> On 12/11/20 4:41 PM, Gedare Bloom wrote:
>> >
>> >
>> > On Fri, Dec 11, 2020 at 8:16 AM Frank Kühndel
>> > > > > wrote:
>> >
>> > Hello Joel,
>> >
>> > On 12/11/20 3:49 PM, Joel Sherrill wrote:
>> > >
>> > >
>> > > On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel
>> > > > > 
>> > > > > >> wrote:
>> > >
>> > > From: Frank Kühndel > > 
>> > > > > >>
>> > >
>> > > ---
>> > >  eng/req/req-for-req.rst | 21 +
>> > >  1 file changed, 21 insertions(+)
>> > >
>> > > diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
>> > > index 9225e95..dcc4c11 100644
>> > > --- a/eng/req/req-for-req.rst
>> > > +++ b/eng/req/req-for-req.rst
>> > > @@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
>> > >
>> > >  ...
>> > >
>> > > +If requirements or the YAML files which contain them are to
>> be
>> > > numbered,
>> > > +the numbering shall start with 0. For example:
>> > >
>> > > +
>> > > +.. code-block:: none
>> > > +
>> > > +weak-alias-0.yml
>> > > +weak-alias-1.yml
>> > > +
>> > > +Smaller numbers shall be prefixed with 0 to the same count of
>> > digits
>> > > +as the largest number. For example:
>> > >
>> > >
>> > > When one goes from 99 to 100 requirements and didn't anticipate
>> having
>> > > that many, does this mean all the files will have to be renamed?
>> >
>> > I can change the text to what Gedare Bloom suggested: "If we know
>> the
>> > max count (N) ahead of time, ..."
>> >
>> > Just from my experience with the requirements for the basedefs,
>> when I
>> > create the requirements for an operation, I know the number I end up
>> > with before checking them in. The issue we discuss would only cause
>> > trouble if later more requirements for the same operation must be
>> added.
>> > This is not totally unlikely but it means that one actually has 9
>> and
>> > then need a 10th one.
>> >
>> > >
>> > > Should we start with a minimum of three or four digits? What would
>> > drive
>> > > the number of requirements in a set? How large of a functional
>> > area will
>> > > a single numbered set contain?
>> > >
>> > > I'm just wondering if it is simpler to just have 001 as a minimum.
>> >
>> > I think that 99 requirements for a single operation are really out
>> of
>> > scope. That will hopefully never ever happen. Even 9 is already a
>> lot.
>> > Also it is rather advisable to adapt the names of the requirements
>> to
>> > indicate the purpose. The numbering is more for the case that there
>> are
>> > two or more requirements on the same topic (like on handling the
>> same
>> > bad input argument).
>> >
>> >   my-function-0
>> >   my-function-1
>> >   my-function-global-side-effect
>> >   my-function-bad-argument-x-error-handling
>> >   my-function-bad-argument-y-error-handling
>> >   my-function-called-in-wrong-state
>> >
>> >
>> > This actually means there is a requirement for unnumbered names as well.
>> >
>> > Would it be better to explicitly define all requirements numbered and
>> > use -0, in case they should be extended later, or perhaps to start
>> > numbering without a number as 0 "implied" and numbers begin with 1?
>> >
>>
>> If there is a -1 then I personally prefer that there should be a -0. For
>> the basedefs, I ended all requirements with -0 even if there was no -1.
>> Yet, whether this is the most wisest thing to do, I cannot say. I would
>> leave it to the author.
>>
>> These numbers are mainly for requirements which need to be split:
>>
>>   my-function.yml
>> "The function shall return 7 and set global variable X to 5".
>>
>> If later someone needs to split this, would renaming it be so much
>> trouble?
>>
>> I don't know if renaming them would be a problem or not. Need an expert
> to weigh in on that.
>
> If renaming them introduces challenges, then we should explicitly use -0
> for the first requirement always, and not allow unnumbered ones to exist.
>

+1

I would be concerned that the unnumbered ones would be following a
different naming pattern which would make the requirements file matching
pattern harder.

>
>
>>   my-function-0.yml
>> "The function shall return 7".
>>
>>   my-function-1.yml
>> "The 

Re: [PATCH v2] eng: Requirements counting shall start at zero

[Gedare Bloom]

On Fri, Dec 11, 2020 at 9:12 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:

> Hello Gedare,
>
> On 12/11/20 4:41 PM, Gedare Bloom wrote:
> >
> >
> > On Fri, Dec 11, 2020 at 8:16 AM Frank Kühndel
> >  > > wrote:
> >
> > Hello Joel,
> >
> > On 12/11/20 3:49 PM, Joel Sherrill wrote:
> > >
> > >
> > > On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel
> > >  > 
> > >  > >> wrote:
> > >
> > > From: Frank Kühndel  > 
> > >  > >>
> > >
> > > ---
> > >  eng/req/req-for-req.rst | 21 +
> > >  1 file changed, 21 insertions(+)
> > >
> > > diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
> > > index 9225e95..dcc4c11 100644
> > > --- a/eng/req/req-for-req.rst
> > > +++ b/eng/req/req-for-req.rst
> > > @@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
> > >
> > >  ...
> > >
> > > +If requirements or the YAML files which contain them are to be
> > > numbered,
> > > +the numbering shall start with 0. For example:
> > >
> > > +
> > > +.. code-block:: none
> > > +
> > > +weak-alias-0.yml
> > > +weak-alias-1.yml
> > > +
> > > +Smaller numbers shall be prefixed with 0 to the same count of
> > digits
> > > +as the largest number. For example:
> > >
> > >
> > > When one goes from 99 to 100 requirements and didn't anticipate
> having
> > > that many, does this mean all the files will have to be renamed?
> >
> > I can change the text to what Gedare Bloom suggested: "If we know the
> > max count (N) ahead of time, ..."
> >
> > Just from my experience with the requirements for the basedefs, when
> I
> > create the requirements for an operation, I know the number I end up
> > with before checking them in. The issue we discuss would only cause
> > trouble if later more requirements for the same operation must be
> added.
> > This is not totally unlikely but it means that one actually has 9 and
> > then need a 10th one.
> >
> > >
> > > Should we start with a minimum of three or four digits? What would
> > drive
> > > the number of requirements in a set? How large of a functional
> > area will
> > > a single numbered set contain?
> > >
> > > I'm just wondering if it is simpler to just have 001 as a minimum.
> >
> > I think that 99 requirements for a single operation are really out of
> > scope. That will hopefully never ever happen. Even 9 is already a
> lot.
> > Also it is rather advisable to adapt the names of the requirements to
> > indicate the purpose. The numbering is more for the case that there
> are
> > two or more requirements on the same topic (like on handling the same
> > bad input argument).
> >
> >   my-function-0
> >   my-function-1
> >   my-function-global-side-effect
> >   my-function-bad-argument-x-error-handling
> >   my-function-bad-argument-y-error-handling
> >   my-function-called-in-wrong-state
> >
> >
> > This actually means there is a requirement for unnumbered names as well.
> >
> > Would it be better to explicitly define all requirements numbered and
> > use -0, in case they should be extended later, or perhaps to start
> > numbering without a number as 0 "implied" and numbers begin with 1?
> >
>
> If there is a -1 then I personally prefer that there should be a -0. For
> the basedefs, I ended all requirements with -0 even if there was no -1.
> Yet, whether this is the most wisest thing to do, I cannot say. I would
> leave it to the author.
>
> These numbers are mainly for requirements which need to be split:
>
>   my-function.yml
> "The function shall return 7 and set global variable X to 5".
>
> If later someone needs to split this, would renaming it be so much trouble?
>
> I don't know if renaming them would be a problem or not. Need an expert to
weigh in on that.

If renaming them introduces challenges, then we should explicitly use -0
for the first requirement always, and not allow unnumbered ones to exist.


>   my-function-0.yml
> "The function shall return 7".
>
>   my-function-1.yml
> "The function shall set global variable X to 5".
>
> Could be as well:
>
>   my-function-result.yml
> "The function shall return 7".
>
>   my-function-side-effect.yml
> "The function shall set global variable X to 5".
>
> Greetings
> Frank
>
> >
> > My opinion is that defining whether we start counting with 0 or with
> 1
> > makes sense. Everything else seems to me a bit 

Re: [PATCH v2] eng: Requirements counting shall start at zero

[Frank Kühndel]

Hello Gedare,

On 12/11/20 4:41 PM, Gedare Bloom wrote:
> 
> 
> On Fri, Dec 11, 2020 at 8:16 AM Frank Kühndel
>  > wrote:
> 
> Hello Joel,
> 
> On 12/11/20 3:49 PM, Joel Sherrill wrote:
> >
> >
> > On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel
> >  
> >  >> wrote:
> >
> >     From: Frank Kühndel  
> >      >>
> >
> >     ---
> >      eng/req/req-for-req.rst | 21 +
> >      1 file changed, 21 insertions(+)
> >
> >     diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
> >     index 9225e95..dcc4c11 100644
> >     --- a/eng/req/req-for-req.rst
> >     +++ b/eng/req/req-for-req.rst
> >     @@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
> >
> >          ...
> >
> >     +If requirements or the YAML files which contain them are to be
> >     numbered,
> >     +the numbering shall start with 0. For example:
> >
> >     +
> >     +.. code-block:: none
> >     +
> >     +    weak-alias-0.yml
> >     +    weak-alias-1.yml
> >     +
> >     +Smaller numbers shall be prefixed with 0 to the same count of
> digits
> >     +as the largest number. For example:
> >
> >
> > When one goes from 99 to 100 requirements and didn't anticipate having
> > that many, does this mean all the files will have to be renamed?
> 
> I can change the text to what Gedare Bloom suggested: "If we know the
> max count (N) ahead of time, ..."
> 
> Just from my experience with the requirements for the basedefs, when I
> create the requirements for an operation, I know the number I end up
> with before checking them in. The issue we discuss would only cause
> trouble if later more requirements for the same operation must be added.
> This is not totally unlikely but it means that one actually has 9 and
> then need a 10th one.
> 
> >
> > Should we start with a minimum of three or four digits? What would
> drive
> > the number of requirements in a set? How large of a functional
> area will
> > a single numbered set contain?
> >
> > I'm just wondering if it is simpler to just have 001 as a minimum.
> 
> I think that 99 requirements for a single operation are really out of
> scope. That will hopefully never ever happen. Even 9 is already a lot.
> Also it is rather advisable to adapt the names of the requirements to
> indicate the purpose. The numbering is more for the case that there are
> two or more requirements on the same topic (like on handling the same
> bad input argument).
> 
>   my-function-0
>   my-function-1
>   my-function-global-side-effect
>   my-function-bad-argument-x-error-handling
>   my-function-bad-argument-y-error-handling
>   my-function-called-in-wrong-state
> 
> 
> This actually means there is a requirement for unnumbered names as well.
> 
> Would it be better to explicitly define all requirements numbered and
> use -0, in case they should be extended later, or perhaps to start
> numbering without a number as 0 "implied" and numbers begin with 1?
> 

If there is a -1 then I personally prefer that there should be a -0. For
the basedefs, I ended all requirements with -0 even if there was no -1.
Yet, whether this is the most wisest thing to do, I cannot say. I would
leave it to the author.

These numbers are mainly for requirements which need to be split:

  my-function.yml
"The function shall return 7 and set global variable X to 5".

If later someone needs to split this, would renaming it be so much trouble?

  my-function-0.yml
"The function shall return 7".

  my-function-1.yml
"The function shall set global variable X to 5".

Could be as well:

  my-function-result.yml
"The function shall return 7".

  my-function-side-effect.yml
"The function shall set global variable X to 5".

Greetings
Frank

> 
> My opinion is that defining whether we start counting with 0 or with 1
> makes sense. Everything else seems to me a bit like solving theoretical
> problems.
> 
> >
> >     +
> >     +.. code-block:: none
> >     +
> >     +    alias-00.yml
> >     +    alias-01.yml
> >     +    alias-02.yml
> >     +    ...
> >     +    alias-09.yml
> >     +    alias-10.yml
> >     +    alias-11.yml
> >     +
> >      Conflict Free Requirements
> >      --
> >
> >     --
> >     2.26.2
> >
> >     ___
> >     devel mailing list
> >     devel@rtems.org 

Re: [PATCH v2] eng: Requirements counting shall start at zero

[Frank Kühndel]

Hello Andrew,

I did not intent to become the authority in numbering files. :-)

Maybe Sebastian has some advice as he knows your application better than
I do. I personally would be pragmatic and do what seems to be an easy to
realize as well as a good solution.

Greetings
Frank



On 12/11/20 4:30 PM, Andrew Butterfield wrote:
> Hello Frank,
> 
>  I have a use case where the numbers will exceed 10 .
> 
> It's not for numbered requirements but numbered test-files.
> These result from different scenarios generated by our SPIN models, as
> part of the qualification activity.
> 
> The files are generated (and numbered) automatically, so the constraints
> are somewhat different.
> 
> For the Events Manager, for example,  I'd expect the final number of
> generated test source files to exceed 10.
> It is unlikely that we would reach 100, though.
> 
> Regards, Andrew
> 
>> On 11 Dec 2020, at 15:16, Frank Kühndel
>> > > wrote:
>>
>> Hello Joel,
>>
>> On 12/11/20 3:49 PM, Joel Sherrill wrote:
>>>
>>>
>>> On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel
>>> >> 
>>> >> >> wrote:
>>>
>>>    From: Frank Kühndel >> 
>>>    >> >>
>>>
>>>    ---
>>> eng/req/req-for-req.rst | 21 +
>>> 1 file changed, 21 insertions(+)
>>>
>>>    diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
>>>    index 9225e95..dcc4c11 100644
>>>    --- a/eng/req/req-for-req.rst
>>>    +++ b/eng/req/req-for-req.rst
>>>    @@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
>>>
>>>     ...
>>>
>>>    +If requirements or the YAML files which contain them are to be
>>>    numbered,
>>>    +the numbering shall start with 0. For example:
>>>
>>>    +
>>>    +.. code-block:: none
>>>    +
>>>    +    weak-alias-0.yml
>>>    +    weak-alias-1.yml
>>>    +
>>>    +Smaller numbers shall be prefixed with 0 to the same count of digits
>>>    +as the largest number. For example:
>>>
>>>
>>> When one goes from 99 to 100 requirements and didn't anticipate having
>>> that many, does this mean all the files will have to be renamed?
>>
>> I can change the text to what Gedare Bloom suggested: "If we know the
>> max count (N) ahead of time, ..."
>>
>> Just from my experience with the requirements for the basedefs, when I
>> create the requirements for an operation, I know the number I end up
>> with before checking them in. The issue we discuss would only cause
>> trouble if later more requirements for the same operation must be added.
>> This is not totally unlikely but it means that one actually has 9 and
>> then need a 10th one.
>>
>>>
>>> Should we start with a minimum of three or four digits? What would drive
>>> the number of requirements in a set? How large of a functional area will
>>> a single numbered set contain?
>>>
>>> I'm just wondering if it is simpler to just have 001 as a minimum.
>>
>> I think that 99 requirements for a single operation are really out of
>> scope. That will hopefully never ever happen. Even 9 is already a lot.
>> Also it is rather advisable to adapt the names of the requirements to
>> indicate the purpose. The numbering is more for the case that there are
>> two or more requirements on the same topic (like on handling the same
>> bad input argument).
>>
>>  my-function-0
>>  my-function-1
>>  my-function-global-side-effect
>>  my-function-bad-argument-x-error-handling
>>  my-function-bad-argument-y-error-handling
>>  my-function-called-in-wrong-state
>>
>> My opinion is that defining whether we start counting with 0 or with 1
>> makes sense. Everything else seems to me a bit like solving theoretical
>> problems.
>>
>>>
>>>    +
>>>    +.. code-block:: none
>>>    +
>>>    +    alias-00.yml
>>>    +    alias-01.yml
>>>    +    alias-02.yml
>>>    +    ...
>>>    +    alias-09.yml
>>>    +    alias-10.yml
>>>    +    alias-11.yml
>>>    +
>>> Conflict Free Requirements
>>> --
>>>
>>>    --
>>>    2.26.2
>>>
>>>    ___
>>>    devel mailing list
>>>    devel@rtems.org  >> >
>>>    http://lists.rtems.org/mailman/listinfo/devel
>>> 
>>>    >> >
>>>
>>
>> Greetings
>> Frank
>> ___
>> devel mailing list
>> devel@rtems.org 
>> http://lists.rtems.org/mailman/listinfo/devel
> 
> 
> Andrew Butterfield     Tel: +353-1-896-2517     Fax: +353-1-677-2204
> Lero@TCD, Head of Software Foundations 

Re: [PATCH v2] eng: Requirements counting shall start at zero

[Gedare Bloom]

On Fri, Dec 11, 2020 at 8:16 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:

> Hello Joel,
>
> On 12/11/20 3:49 PM, Joel Sherrill wrote:
> >
> >
> > On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel
> >  > > wrote:
> >
> > From: Frank Kühndel  > >
> >
> > ---
> >  eng/req/req-for-req.rst | 21 +
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
> > index 9225e95..dcc4c11 100644
> > --- a/eng/req/req-for-req.rst
> > +++ b/eng/req/req-for-req.rst
> > @@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
> >
> >  ...
> >
> > +If requirements or the YAML files which contain them are to be
> > numbered,
> > +the numbering shall start with 0. For example:
> >
> > +
> > +.. code-block:: none
> > +
> > +weak-alias-0.yml
> > +weak-alias-1.yml
> > +
> > +Smaller numbers shall be prefixed with 0 to the same count of digits
> > +as the largest number. For example:
> >
> >
> > When one goes from 99 to 100 requirements and didn't anticipate having
> > that many, does this mean all the files will have to be renamed?
>
> I can change the text to what Gedare Bloom suggested: "If we know the
> max count (N) ahead of time, ..."
>
> Just from my experience with the requirements for the basedefs, when I
> create the requirements for an operation, I know the number I end up
> with before checking them in. The issue we discuss would only cause
> trouble if later more requirements for the same operation must be added.
> This is not totally unlikely but it means that one actually has 9 and
> then need a 10th one.
>
> >
> > Should we start with a minimum of three or four digits? What would drive
> > the number of requirements in a set? How large of a functional area will
> > a single numbered set contain?
> >
> > I'm just wondering if it is simpler to just have 001 as a minimum.
>
> I think that 99 requirements for a single operation are really out of
> scope. That will hopefully never ever happen. Even 9 is already a lot.
> Also it is rather advisable to adapt the names of the requirements to
> indicate the purpose. The numbering is more for the case that there are
> two or more requirements on the same topic (like on handling the same
> bad input argument).
>
>   my-function-0
>   my-function-1
>   my-function-global-side-effect
>   my-function-bad-argument-x-error-handling
>   my-function-bad-argument-y-error-handling
>   my-function-called-in-wrong-state
>

This actually means there is a requirement for unnumbered names as well.

Would it be better to explicitly define all requirements numbered and use
-0, in case they should be extended later, or perhaps to start numbering
without a number as 0 "implied" and numbers begin with 1?



>
> My opinion is that defining whether we start counting with 0 or with 1
> makes sense. Everything else seems to me a bit like solving theoretical
> problems.
>
> >
> > +
> > +.. code-block:: none
> > +
> > +alias-00.yml
> > +alias-01.yml
> > +alias-02.yml
> > +...
> > +alias-09.yml
> > +alias-10.yml
> > +alias-11.yml
> > +
> >  Conflict Free Requirements
> >  --
> >
> > --
> > 2.26.2
> >
> > ___
> > devel mailing list
> > devel@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel
> > 
> >
>
> Greetings
> Frank
> ___
> 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 v2] eng: Requirements counting shall start at zero

[Andrew Butterfield]

Hello Frank,

 I have a use case where the numbers will exceed 10 .

It's not for numbered requirements but numbered test-files.
These result from different scenarios generated by our SPIN models, as part of 
the qualification activity.

The files are generated (and numbered) automatically, so the constraints are 
somewhat different.

For the Events Manager, for example,  I'd expect the final number of generated 
test source files to exceed 10.
It is unlikely that we would reach 100, though.

Regards, Andrew

> On 11 Dec 2020, at 15:16, Frank Kühndel  
> wrote:
> 
> Hello Joel,
> 
> On 12/11/20 3:49 PM, Joel Sherrill wrote:
>> 
>> 
>> On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel
>> > > wrote:
>> 
>>From: Frank Kühndel >>
>> 
>>---
>> eng/req/req-for-req.rst | 21 +
>> 1 file changed, 21 insertions(+)
>> 
>>diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
>>index 9225e95..dcc4c11 100644
>>--- a/eng/req/req-for-req.rst
>>+++ b/eng/req/req-for-req.rst
>>@@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
>> 
>> ...
>> 
>>+If requirements or the YAML files which contain them are to be
>>numbered,
>>+the numbering shall start with 0. For example:
>> 
>>+
>>+.. code-block:: none
>>+
>>+weak-alias-0.yml
>>+weak-alias-1.yml
>>+
>>+Smaller numbers shall be prefixed with 0 to the same count of digits
>>+as the largest number. For example:
>> 
>> 
>> When one goes from 99 to 100 requirements and didn't anticipate having
>> that many, does this mean all the files will have to be renamed?
> 
> I can change the text to what Gedare Bloom suggested: "If we know the
> max count (N) ahead of time, ..."
> 
> Just from my experience with the requirements for the basedefs, when I
> create the requirements for an operation, I know the number I end up
> with before checking them in. The issue we discuss would only cause
> trouble if later more requirements for the same operation must be added.
> This is not totally unlikely but it means that one actually has 9 and
> then need a 10th one.
> 
>> 
>> Should we start with a minimum of three or four digits? What would drive
>> the number of requirements in a set? How large of a functional area will
>> a single numbered set contain?
>> 
>> I'm just wondering if it is simpler to just have 001 as a minimum.
> 
> I think that 99 requirements for a single operation are really out of
> scope. That will hopefully never ever happen. Even 9 is already a lot.
> Also it is rather advisable to adapt the names of the requirements to
> indicate the purpose. The numbering is more for the case that there are
> two or more requirements on the same topic (like on handling the same
> bad input argument).
> 
>  my-function-0
>  my-function-1
>  my-function-global-side-effect
>  my-function-bad-argument-x-error-handling
>  my-function-bad-argument-y-error-handling
>  my-function-called-in-wrong-state
> 
> My opinion is that defining whether we start counting with 0 or with 1
> makes sense. Everything else seems to me a bit like solving theoretical
> problems.
> 
>> 
>>+
>>+.. code-block:: none
>>+
>>+alias-00.yml
>>+alias-01.yml
>>+alias-02.yml
>>+...
>>+alias-09.yml
>>+alias-10.yml
>>+alias-11.yml
>>+
>> Conflict Free Requirements
>> --
>> 
>>-- 
>>2.26.2
>> 
>>___
>>devel mailing list
>>devel@rtems.org 
>>http://lists.rtems.org/mailman/listinfo/devel
>>
>> 
> 
> Greetings
> Frank
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero@TCD, Head of Software Foundations & Verification Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
 http://www.scss.tcd.ie/Andrew.Butterfield/


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

Re: [PATCH v2] eng: Requirements counting shall start at zero

[Frank Kühndel]

Hello Joel,

On 12/11/20 3:49 PM, Joel Sherrill wrote:
> 
> 
> On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel
>  > wrote:
> 
> From: Frank Kühndel  >
> 
> ---
>  eng/req/req-for-req.rst | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
> index 9225e95..dcc4c11 100644
> --- a/eng/req/req-for-req.rst
> +++ b/eng/req/req-for-req.rst
> @@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
> 
>      ...
> 
> +If requirements or the YAML files which contain them are to be
> numbered,
> +the numbering shall start with 0. For example:
> 
> +
> +.. code-block:: none
> +
> +    weak-alias-0.yml
> +    weak-alias-1.yml
> +
> +Smaller numbers shall be prefixed with 0 to the same count of digits
> +as the largest number. For example:
> 
> 
> When one goes from 99 to 100 requirements and didn't anticipate having
> that many, does this mean all the files will have to be renamed?

I can change the text to what Gedare Bloom suggested: "If we know the
max count (N) ahead of time, ..."

Just from my experience with the requirements for the basedefs, when I
create the requirements for an operation, I know the number I end up
with before checking them in. The issue we discuss would only cause
trouble if later more requirements for the same operation must be added.
This is not totally unlikely but it means that one actually has 9 and
then need a 10th one.

> 
> Should we start with a minimum of three or four digits? What would drive
> the number of requirements in a set? How large of a functional area will
> a single numbered set contain?
> 
> I'm just wondering if it is simpler to just have 001 as a minimum.

I think that 99 requirements for a single operation are really out of
scope. That will hopefully never ever happen. Even 9 is already a lot.
Also it is rather advisable to adapt the names of the requirements to
indicate the purpose. The numbering is more for the case that there are
two or more requirements on the same topic (like on handling the same
bad input argument).

  my-function-0
  my-function-1
  my-function-global-side-effect
  my-function-bad-argument-x-error-handling
  my-function-bad-argument-y-error-handling
  my-function-called-in-wrong-state

My opinion is that defining whether we start counting with 0 or with 1
makes sense. Everything else seems to me a bit like solving theoretical
problems.

> 
> +
> +.. code-block:: none
> +
> +    alias-00.yml
> +    alias-01.yml
> +    alias-02.yml
> +    ...
> +    alias-09.yml
> +    alias-10.yml
> +    alias-11.yml
> +
>  Conflict Free Requirements
>  --
> 
> -- 
> 2.26.2
> 
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 
> 

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

RE: [PATCH 1/2] tm27: Use generic cpu index accessor

[Kinsey Moore]

-Original Message-
From: Sebastian Huber  
Sent: Thursday, December 10, 2020 23:48
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH 1/2] tm27: Use generic cpu index accessor

> On 10/12/2020 21:42, Kinsey Moore wrote:
>> The arm_cp15 function for accessing the current CPU index is specific
>> to ARMv7 while this header is used for ARMv8 as well. Instead, use a
>> generic accessor that is part of the standard CPU API.
>
> I am fine with this fix, however, this is basically now the same 
> approach as in my v2 patch:
>
> https://lists.rtems.org/pipermail/devel/2020-December/063693.html
>
> Since the tm27 test is configured to use only one CPU, the current 
> processor is always 0.

Unfortunately, that's the only API currently available to get that information 
easily on both architectures. The base function that is wrapped 
(_CPU_SMP_Get_current_processor) could be provided outside the RTEMS_SMP ifdef 
block and that could be used instead since this is specific to ARM/AArch64. 
Would that be acceptable?

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

Re: [PATCH v2] eng: Requirements counting shall start at zero

[Joel Sherrill]

On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel <
frank.kuehn...@embedded-brains.de> wrote:

> From: Frank Kühndel 
>
> ---
>  eng/req/req-for-req.rst | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
> index 9225e95..dcc4c11 100644
> --- a/eng/req/req-for-req.rst
> +++ b/eng/req/req-for-req.rst
> @@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
>
>  ...
>
> +If requirements or the YAML files which contain them are to be numbered,
> +the numbering shall start with 0. For example:

+
> +.. code-block:: none
> +
> +weak-alias-0.yml
> +weak-alias-1.yml
> +
> +Smaller numbers shall be prefixed with 0 to the same count of digits
> +as the largest number. For example:
>

When one goes from 99 to 100 requirements and didn't anticipate having that
many, does this mean all the files will have to be renamed?

Should we start with a minimum of three or four digits? What would drive
the number of requirements in a set? How large of a functional area will a
single numbered set contain?

I'm just wondering if it is simpler to just have 001 as a minimum.

+
> +.. code-block:: none
> +
> +alias-00.yml
> +alias-01.yml
> +alias-02.yml
> +...
> +alias-09.yml
> +alias-10.yml
> +alias-11.yml
> +
>  Conflict Free Requirements
>  --
>
> --
> 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

[PATCH v2] eng: Requirements counting shall start at zero

[Frank Kuehndel]

From: Frank Kühndel 

---
 eng/req/req-for-req.rst | 21 +
 1 file changed, 21 insertions(+)

diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
index 9225e95..dcc4c11 100644
--- a/eng/req/req-for-req.rst
+++ b/eng/req/req-for-req.rst
@@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
 
 ...
 
+If requirements or the YAML files which contain them are to be numbered,
+the numbering shall start with 0. For example:
+
+.. code-block:: none
+
+weak-alias-0.yml
+weak-alias-1.yml
+
+Smaller numbers shall be prefixed with 0 to the same count of digits
+as the largest number. For example:
+
+.. code-block:: none
+
+alias-00.yml
+alias-01.yml
+alias-02.yml
+...
+alias-09.yml
+alias-10.yml
+alias-11.yml
+
 Conflict Free Requirements
 --
 
-- 
2.26.2

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

Re: [PATCH] tester: Add configs for AArch64 ZynqMP BSPs

[Gedare Bloom]

looks ok to push assuming it works :)

On Tue, Dec 8, 2020 at 11:03 AM Kinsey Moore 
wrote:

> ---
>  .../testing/bsps/xilinx_zynqmp_ilp32.ini  | 38 +++
>  .../rtems/testing/bsps/xilinx_zynqmp_lp64.ini | 38 +++
>  2 files changed, 76 insertions(+)
>  create mode 100644 tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
>  create mode 100644 tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini
>
> diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
> b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
> new file mode 100644
> index 000..5ff0e86
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
> @@ -0,0 +1,38 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2020 Kinsey Moore(kinsey.mo...@oarcorp.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are
> met:
> +#
> +# 1. Redistributions of source code must retain the above copyright
> notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright
> notice,
> +# this list of conditions and the following disclaimer in the
> documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
> BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> +# POSSIBILITY OF SUCH DAMAGE.
> +#
> +
> +#
> +# The AArch64 Xilinx ZynqMP (Ultrascale+ MPSOC) ILP32 BSP.
> +#
> +[xilinx_zynqmp_ilp32]
> +bsp   = xilinx_zynqmp_ilp32
> +arch  = aarch64
> +tester= %{_rtscripts}/qemu.cfg
> +bsp_qemu_opts = %{qemu_opts_base} -serial null -serial mon:stdio -machine
> xlnx-zcu102 -m 4096
> diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini
> b/tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini
> new file mode 100644
> index 000..8db82b6
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini
> @@ -0,0 +1,38 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2020 Kinsey Moore(kinsey.mo...@oarcorp.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are
> met:
> +#
> +# 1. Redistributions of source code must retain the above copyright
> notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright
> notice,
> +# this list of conditions and the following disclaimer in the
> documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
> BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> +# POSSIBILITY OF SUCH DAMAGE.
> +#
> +
> +#
> +# The AArch64 Xilinx ZynqMP (Ultrascale+ MPSOC) LP64 BSP.
> +#
> +[xilinx_zynqmp_lp64]
> +bsp   = xilinx_zynqmp_lp64
> +arch  = aarch64
> +tester= %{_rtscripts}/qemu.cfg
> +bsp_qemu_opts = %{qemu_opts_base} -serial null -serial mon:stdio -machine
> xlnx-zcu102 -m 4096
> --
> 2.20.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 2/3] user: Add A53 Qemu run instructions

[Gedare Bloom]

On Tue, Dec 8, 2020 at 11:03 AM Kinsey Moore 
wrote:

> ---
>  user/bsps/aarch64/a53.rst | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/user/bsps/aarch64/a53.rst b/user/bsps/aarch64/a53.rst
> index 73735b1..e3a89f8 100644
> --- a/user/bsps/aarch64/a53.rst
> +++ b/user/bsps/aarch64/a53.rst
> @@ -25,3 +25,10 @@ Console Driver
>  --
>
>  The console driver supports the default Qemu emulated ARM PL011 PrimeCell
> UART.
> +
> +Running Executables
> +---
> +
> +Executables generated by these BSPs can be run using the following
> command::
> +
> +qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio -machine
> virt,gic_version=3 -cpu cortex-a53 -m 4096 -kernel example.exe
>

Check the line break on PDF, maybe typeset an explicit line break \



-- 
> 2.20.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 5/5] bsps/arm: Move BSP_START_IN_HYP_SUPPORT option

[Gedare Bloom]

On Wed, Dec 9, 2020 at 9:50 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Clarify documentation.
>
> Update #4202.
> ---
>  .../bsps/arm/{raspberrypi/optenhyp.yml => optstarthyp.yml} | 3 ++-
>  spec/build/bsps/arm/raspberrypi/grp.yml| 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>  rename spec/build/bsps/arm/{raspberrypi/optenhyp.yml => optstarthyp.yml}
> (74%)
>
> diff --git a/spec/build/bsps/arm/raspberrypi/optenhyp.yml
> b/spec/build/bsps/arm/optstarthyp.yml
> similarity index 74%
> rename from spec/build/bsps/arm/raspberrypi/optenhyp.yml
> rename to spec/build/bsps/arm/optstarthyp.yml
> index b9b9cb89ae..d21db5ad4f 100644
> --- a/spec/build/bsps/arm/raspberrypi/optenhyp.yml
> +++ b/spec/build/bsps/arm/optstarthyp.yml
> @@ -8,7 +8,8 @@ copyrights:
>  default: true
>  default-by-variant: []
>  description: |
> -  Support start of BSP in ARM HYP mode
> +  If set to true, then the a system start in hypervisor mode (EL2) is
>
s/the a/a


> +  supported, otherwise it is unsupported.
>  enabled-by: true
>  links: []
>  name: BSP_START_IN_HYP_SUPPORT
> diff --git a/spec/build/bsps/arm/raspberrypi/grp.yml
> b/spec/build/bsps/arm/raspberrypi/grp.yml
> index e28f387c8d..4a86c5c688 100644
> --- a/spec/build/bsps/arm/raspberrypi/grp.yml
> +++ b/spec/build/bsps/arm/raspberrypi/grp.yml
> @@ -16,7 +16,7 @@ links:
>  - role: build-dependency
>uid: objsmp
>  - role: build-dependency
> -  uid: optenhyp
> +  uid: ../optstarthyp
>  - role: build-dependency
>uid: opti2ciomode
>  - role: build-dependency
> --
> 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] eng: Requirements counting shall start at zero

[Gedare Bloom]

I don't mind starting 0 or 1, consistency is important.

If we know the max count (N) ahead of time, it can be helpful to generate
with a 0-padded number. This makes every name a consistent size and can be
sorted lexicographically.

On Wed, Dec 9, 2020 at 6:50 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Andrew,
>
> On 09/12/2020 14:47, Andrew Butterfield wrote:
> >  I plan to generate numbered test sources - should these also be
> > numbered from 0?
> > E.g.  tr-model-events-mgr-n.c  - I was going to have `n` range from
> > 1..N -- should I adopt the same convention as you suggest for
> consistency?
> if we agree on this change, then the test file numbering should also
> start from 0.
>
> --
> 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] config: Fix invalid static assertions in C

[Joel Sherrill]

On Fri, Dec 11, 2020, 7:26 AM Gedare Bloom  wrote:

> Hi Sebastian,
>
> On Fri, Dec 11, 2020 at 5:57 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Expressions in static assertions must be integral constant expressions.
>> In
>> integral constant expressions the use of address constant expressions is
>> not
>> allowed.
>>
>> In static initializers the address constant expressions are allowed.
>> Introduce
>> a new macro _CONFIGURE_ASSERT_NOT_NULL() which leads to a compile time
>> error if
>> the second parameter is NULL.  It generates error messages like this if
>> for
>> example
>>
>>   #define CONFIGURE_INIT_TASK_ENTRY_POINT NULL
>>
>> is provided by the application:
>>
>> cpukit/include/rtems/confdefs/inittask.h:51:26: error: size of unnamed
>> array is negative
>>51 | ( _type ) sizeof( int[ ( _value ) != NULL ? 1 : -1 ] ) )
>>   |  ^
>> cpukit/include/rtems/confdefs/inittask.h:170:3: note: in expansion of
>> macro '_CONFIGURE_ASSERT_NOT_NULL'
>>   170 |   _CONFIGURE_ASSERT_NOT_NULL(
>>   |   ^~
>>
>>
> This is a nice fix. The initial error is opaque, but the macro expansion
> seems to be clear enough to help a user debug. Thanks
>
+1

If this was done because of a Coverity flagged issue, please include the
CID in the commit message





>
>
>> Update #4181.
>> ---
>>  cpukit/include/rtems/confdefs/inittask.h | 27 +++
>>  cpukit/include/rtems/confdefs/wkspace.h  | 34 +++-
>>  2 files changed, 32 insertions(+), 29 deletions(-)
>>
>> diff --git a/cpukit/include/rtems/confdefs/inittask.h
>> b/cpukit/include/rtems/confdefs/inittask.h
>> index d5ba521bf9..9dbf0b967b 100644
>> --- a/cpukit/include/rtems/confdefs/inittask.h
>> +++ b/cpukit/include/rtems/confdefs/inittask.h
>> @@ -46,6 +46,10 @@
>>
>>  #ifdef CONFIGURE_INIT
>>
>> +#define _CONFIGURE_ASSERT_NOT_NULL( _type, _value ) \
>> +  ( ( _value ) != NULL ? ( _value ) : \
>> +( _type ) sizeof( int[ ( _value ) != NULL ? 1 : -1 ] ) )
>> +
>>
> Magic ;)
>
>
>>  #ifdef CONFIGURE_RTEMS_INIT_TASKS_TABLE
>>
>>  #include 
>> @@ -94,8 +98,8 @@ extern "C" {
>>  #endif
>>
>>  /*
>> - * Ignore the following warnings from g++ and clang in the static
>> assertion
>> - * below:
>> + * Ignore the following warnings from g++ and clang in the uses of
>> + * _CONFIGURE_ASSERT_NOT_NULL() below:
>>   *
>>   * warning: the address of 'void Init()' will never be NULL [-Waddress]
>>   *
>> @@ -107,13 +111,6 @@ extern "C" {
>>  #pragma GCC diagnostic ignored "-Wpragmas"
>>  #pragma GCC diagnostic ignored "-Wtautological-pointer-compare"
>>
>> -RTEMS_STATIC_ASSERT(
>> -  CONFIGURE_INIT_TASK_ENTRY_POINT != NULL,
>> -  CONFIGURE_INIT_TASK_ENTRY_POINT_MUST_NOT_BE_NULL
>> -);
>> -
>> -#pragma GCC diagnostic pop
>> -
>>  #ifdef CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE
>>
>>  #ifdef CONFIGURE_INIT_TASK_STACK_SIZE
>> @@ -139,7 +136,10 @@ const RTEMS_tasks_User_task_config
>> _RTEMS_tasks_User_task_config = {
>>  CONFIGURE_INIT_TASK_INITIAL_MODES,
>>  CONFIGURE_INIT_TASK_ATTRIBUTES,
>>},
>> -  CONFIGURE_INIT_TASK_ENTRY_POINT,
>> +  _CONFIGURE_ASSERT_NOT_NULL(
>> +rtems_task_entry,
>> +CONFIGURE_INIT_TASK_ENTRY_POINT
>> +  ),
>>CONFIGURE_INIT_TASK_ARGUMENTS
>>  };
>>
>> @@ -167,7 +167,10 @@ const rtems_initialization_tasks_table
>> _RTEMS_tasks_User_task_table = {
>>CONFIGURE_INIT_TASK_STACK_SIZE,
>>CONFIGURE_INIT_TASK_PRIORITY,
>>CONFIGURE_INIT_TASK_ATTRIBUTES,
>> -  CONFIGURE_INIT_TASK_ENTRY_POINT,
>> +  _CONFIGURE_ASSERT_NOT_NULL(
>> +rtems_task_entry,
>> +CONFIGURE_INIT_TASK_ENTRY_POINT
>> +  ),
>>CONFIGURE_INIT_TASK_INITIAL_MODES,
>>CONFIGURE_INIT_TASK_ARGUMENTS
>>  };
>> @@ -180,6 +183,8 @@ RTEMS_SYSINIT_ITEM(
>>
>>  #endif /* CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE */
>>
>> +#pragma GCC diagnostic pop
>> +
>>  #ifdef __cplusplus
>>  }
>>  #endif
>> diff --git a/cpukit/include/rtems/confdefs/wkspace.h
>> b/cpukit/include/rtems/confdefs/wkspace.h
>> index 39014d7f1d..eac4bdb4bd 100644
>> --- a/cpukit/include/rtems/confdefs/wkspace.h
>> +++ b/cpukit/include/rtems/confdefs/wkspace.h
>> @@ -139,8 +139,8 @@ const uintptr_t _Stack_Space_size =
>> _CONFIGURE_STACK_SPACE_SIZE;
>>  #if defined(CONFIGURE_TASK_STACK_ALLOCATOR) \
>>&& defined(CONFIGURE_TASK_STACK_DEALLOCATOR)
>>/*
>> -   * Ignore the following warnings from g++ and clang in the static
>> assertions
>> -   * below:
>> +   * Ignore the following warnings from g++ and clang in the uses of
>> +   * _CONFIGURE_ASSERT_NOT_NULL() below:
>> *
>> * warning: the address of 'f()' will never be NULL [-Waddress]
>> *
>> @@ -159,13 +159,11 @@ const uintptr_t _Stack_Space_size =
>> _CONFIGURE_STACK_SPACE_SIZE;
>>#endif
>>
>>#ifdef CONFIGURE_TASK_STACK_ALLOCATOR_INIT
>> -RTEMS_STATIC_ASSERT(
>> -  CONFIGURE_TASK_STACK_ALLOCATOR_INIT != NULL,
>> -  CONFIGURE_TASK_STACK_ALLOCATOR_INIT_MUST_NOT_BE_NULL
>> -);
>> -
>>  

Re: [PATCH] config: Fix invalid static assertions in C

[Gedare Bloom]

Hi Sebastian,

On Fri, Dec 11, 2020 at 5:57 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Expressions in static assertions must be integral constant expressions.  In
> integral constant expressions the use of address constant expressions is
> not
> allowed.
>
> In static initializers the address constant expressions are allowed.
> Introduce
> a new macro _CONFIGURE_ASSERT_NOT_NULL() which leads to a compile time
> error if
> the second parameter is NULL.  It generates error messages like this if for
> example
>
>   #define CONFIGURE_INIT_TASK_ENTRY_POINT NULL
>
> is provided by the application:
>
> cpukit/include/rtems/confdefs/inittask.h:51:26: error: size of unnamed
> array is negative
>51 | ( _type ) sizeof( int[ ( _value ) != NULL ? 1 : -1 ] ) )
>   |  ^
> cpukit/include/rtems/confdefs/inittask.h:170:3: note: in expansion of
> macro '_CONFIGURE_ASSERT_NOT_NULL'
>   170 |   _CONFIGURE_ASSERT_NOT_NULL(
>   |   ^~
>
>
This is a nice fix. The initial error is opaque, but the macro expansion
seems to be clear enough to help a user debug. Thanks


> Update #4181.
> ---
>  cpukit/include/rtems/confdefs/inittask.h | 27 +++
>  cpukit/include/rtems/confdefs/wkspace.h  | 34 +++-
>  2 files changed, 32 insertions(+), 29 deletions(-)
>
> diff --git a/cpukit/include/rtems/confdefs/inittask.h
> b/cpukit/include/rtems/confdefs/inittask.h
> index d5ba521bf9..9dbf0b967b 100644
> --- a/cpukit/include/rtems/confdefs/inittask.h
> +++ b/cpukit/include/rtems/confdefs/inittask.h
> @@ -46,6 +46,10 @@
>
>  #ifdef CONFIGURE_INIT
>
> +#define _CONFIGURE_ASSERT_NOT_NULL( _type, _value ) \
> +  ( ( _value ) != NULL ? ( _value ) : \
> +( _type ) sizeof( int[ ( _value ) != NULL ? 1 : -1 ] ) )
> +
>
Magic ;)


>  #ifdef CONFIGURE_RTEMS_INIT_TASKS_TABLE
>
>  #include 
> @@ -94,8 +98,8 @@ extern "C" {
>  #endif
>
>  /*
> - * Ignore the following warnings from g++ and clang in the static
> assertion
> - * below:
> + * Ignore the following warnings from g++ and clang in the uses of
> + * _CONFIGURE_ASSERT_NOT_NULL() below:
>   *
>   * warning: the address of 'void Init()' will never be NULL [-Waddress]
>   *
> @@ -107,13 +111,6 @@ extern "C" {
>  #pragma GCC diagnostic ignored "-Wpragmas"
>  #pragma GCC diagnostic ignored "-Wtautological-pointer-compare"
>
> -RTEMS_STATIC_ASSERT(
> -  CONFIGURE_INIT_TASK_ENTRY_POINT != NULL,
> -  CONFIGURE_INIT_TASK_ENTRY_POINT_MUST_NOT_BE_NULL
> -);
> -
> -#pragma GCC diagnostic pop
> -
>  #ifdef CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE
>
>  #ifdef CONFIGURE_INIT_TASK_STACK_SIZE
> @@ -139,7 +136,10 @@ const RTEMS_tasks_User_task_config
> _RTEMS_tasks_User_task_config = {
>  CONFIGURE_INIT_TASK_INITIAL_MODES,
>  CONFIGURE_INIT_TASK_ATTRIBUTES,
>},
> -  CONFIGURE_INIT_TASK_ENTRY_POINT,
> +  _CONFIGURE_ASSERT_NOT_NULL(
> +rtems_task_entry,
> +CONFIGURE_INIT_TASK_ENTRY_POINT
> +  ),
>CONFIGURE_INIT_TASK_ARGUMENTS
>  };
>
> @@ -167,7 +167,10 @@ const rtems_initialization_tasks_table
> _RTEMS_tasks_User_task_table = {
>CONFIGURE_INIT_TASK_STACK_SIZE,
>CONFIGURE_INIT_TASK_PRIORITY,
>CONFIGURE_INIT_TASK_ATTRIBUTES,
> -  CONFIGURE_INIT_TASK_ENTRY_POINT,
> +  _CONFIGURE_ASSERT_NOT_NULL(
> +rtems_task_entry,
> +CONFIGURE_INIT_TASK_ENTRY_POINT
> +  ),
>CONFIGURE_INIT_TASK_INITIAL_MODES,
>CONFIGURE_INIT_TASK_ARGUMENTS
>  };
> @@ -180,6 +183,8 @@ RTEMS_SYSINIT_ITEM(
>
>  #endif /* CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE */
>
> +#pragma GCC diagnostic pop
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/cpukit/include/rtems/confdefs/wkspace.h
> b/cpukit/include/rtems/confdefs/wkspace.h
> index 39014d7f1d..eac4bdb4bd 100644
> --- a/cpukit/include/rtems/confdefs/wkspace.h
> +++ b/cpukit/include/rtems/confdefs/wkspace.h
> @@ -139,8 +139,8 @@ const uintptr_t _Stack_Space_size =
> _CONFIGURE_STACK_SPACE_SIZE;
>  #if defined(CONFIGURE_TASK_STACK_ALLOCATOR) \
>&& defined(CONFIGURE_TASK_STACK_DEALLOCATOR)
>/*
> -   * Ignore the following warnings from g++ and clang in the static
> assertions
> -   * below:
> +   * Ignore the following warnings from g++ and clang in the uses of
> +   * _CONFIGURE_ASSERT_NOT_NULL() below:
> *
> * warning: the address of 'f()' will never be NULL [-Waddress]
> *
> @@ -159,13 +159,11 @@ const uintptr_t _Stack_Space_size =
> _CONFIGURE_STACK_SPACE_SIZE;
>#endif
>
>#ifdef CONFIGURE_TASK_STACK_ALLOCATOR_INIT
> -RTEMS_STATIC_ASSERT(
> -  CONFIGURE_TASK_STACK_ALLOCATOR_INIT != NULL,
> -  CONFIGURE_TASK_STACK_ALLOCATOR_INIT_MUST_NOT_BE_NULL
> -);
> -
>  const Stack_Allocator_initialize _Stack_Allocator_initialize =
> -  CONFIGURE_TASK_STACK_ALLOCATOR_INIT;
> +  _CONFIGURE_ASSERT_NOT_NULL(
> +Stack_Allocator_initialize,
> +CONFIGURE_TASK_STACK_ALLOCATOR_INIT
> +  );
>
>  RTEMS_SYSINIT_ITEM(
>_Stack_Allocator_do_initialize,
> @@ 

[PATCH] Add GMP as a prerequisite for GDB

[Sebastian Huber]

---
 bare/config/devel/gmp-6.1.0.cfg   | 18 ++
 rtems/config/6/rtems-default.bset |  1 +
 rtems/config/7/rtems-default.bset |  1 +
 source-builder/config/gmp.cfg | 60 +++
 4 files changed, 80 insertions(+)
 create mode 100644 bare/config/devel/gmp-6.1.0.cfg
 create mode 100644 source-builder/config/gmp.cfg

diff --git a/bare/config/devel/gmp-6.1.0.cfg b/bare/config/devel/gmp-6.1.0.cfg
new file mode 100644
index 000..7bedba9
--- /dev/null
+++ b/bare/config/devel/gmp-6.1.0.cfg
@@ -0,0 +1,18 @@
+#
+# GMP 6.1.0
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%define gmp_version 6.1.0
+
+%hash sha512 gmp-%{gmp_version}.tar.bz2 
3c82aeab9c1596d4da8afac2eec38e429e84f3211e1a572cf8fd2b546493c44c039b922a1133eaaa48bd7f3e11dbe795a384e21ed95cbe3ecc58d7ac02246117
+
+#
+# The GMP build instructions.
+#
+%include %{_configdir}/gmp.cfg
diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index 0dc2e77..220778c 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -11,6 +11,7 @@
 #
 
 devel/expat-2.1.0-1
+devel/gmp-6.1.0
 tools/rtems-gdb-head
 
 tools/rtems-binutils-head
diff --git a/rtems/config/7/rtems-default.bset 
b/rtems/config/7/rtems-default.bset
index b37d75f..acb7059 100644
--- a/rtems/config/7/rtems-default.bset
+++ b/rtems/config/7/rtems-default.bset
@@ -6,6 +6,7 @@
 #
 
 devel/expat-2.1.0-1
+devel/gmp-6.1.0
 tools/rtems-gdb-head
 
 tools/rtems-binutils-head
diff --git a/source-builder/config/gmp.cfg b/source-builder/config/gmp.cfg
new file mode 100644
index 000..0e9118e
--- /dev/null
+++ b/source-builder/config/gmp.cfg
@@ -0,0 +1,60 @@
+#
+# The GNU Multiple Precision Arithmetic Library (GMP)
+#
+# This configuration file configure's, make's and install's GMP.
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+Name:  gmp-%{gmp_version}-%{_host}-%{release}
+Summary:   The GNU Multiple Precision Arithmetic Library (GMP) v%{gmp_version} 
for target %{_target} on host %{_host}
+Version:   %{gmp_version}
+Release:   %{release}
+URL:  https://gmplib.org/
+
+#
+# Source
+#
+%source set gmp 
https://gcc.gnu.org/pub/gcc/infrastructure/gmp-%{gmp_version}.tar.bz2
+
+#
+# Prepare the source code.
+#
+%prep
+  build_top=$(pwd)
+
+  %source setup gmp -q -n gmp-%{gmp_version}
+  %patch setup gmp -p1
+
+  cd ${build_top}
+
+%build
+  build_top=$(pwd)
+
+  cd gmp-%{gmp_version}
+
+  %{host_build_flags}
+
+  ./configure \
+--build=%{_build} --host=%{_host} \
+--verbose \
+--prefix=%{_prefix} --bindir=%{_bindir} \
+--exec-prefix=%{_exec_prefix} \
+--includedir=%{_includedir} --libdir=%{_libdir} \
+--mandir=%{_mandir} --infodir=%{_infodir}
+
+  %{__make} %{?_smp_mflags} all
+
+  cd ${build_top}
+
+%install
+  build_top=$(pwd)
+
+  rm -rf $SB_BUILD_ROOT
+
+  cd gmp-%{gmp_version}
+  %{__make} DESTDIR=$SB_BUILD_ROOT install
+
+  cd ${build_top}
-- 
2.26.2

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

Re: [PATCH v2 0/1] xilinx_zynq: Enable support for 4kiB MMU pages

[Sebastian Huber]

On 11/12/2020 11:02, jan.som...@dlr.de wrote:

Could someone please push these changes?
I think this is the last patchset from me which is open.


I check it in with minor modifications.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] config: Fix invalid static assertions in C

[Sebastian Huber]

Expressions in static assertions must be integral constant expressions.  In
integral constant expressions the use of address constant expressions is not
allowed.

In static initializers the address constant expressions are allowed.  Introduce
a new macro _CONFIGURE_ASSERT_NOT_NULL() which leads to a compile time error if
the second parameter is NULL.  It generates error messages like this if for
example

  #define CONFIGURE_INIT_TASK_ENTRY_POINT NULL

is provided by the application:

cpukit/include/rtems/confdefs/inittask.h:51:26: error: size of unnamed array is 
negative
   51 | ( _type ) sizeof( int[ ( _value ) != NULL ? 1 : -1 ] ) )
  |  ^
cpukit/include/rtems/confdefs/inittask.h:170:3: note: in expansion of macro 
'_CONFIGURE_ASSERT_NOT_NULL'
  170 |   _CONFIGURE_ASSERT_NOT_NULL(
  |   ^~

Update #4181.
---
 cpukit/include/rtems/confdefs/inittask.h | 27 +++
 cpukit/include/rtems/confdefs/wkspace.h  | 34 +++-
 2 files changed, 32 insertions(+), 29 deletions(-)

diff --git a/cpukit/include/rtems/confdefs/inittask.h 
b/cpukit/include/rtems/confdefs/inittask.h
index d5ba521bf9..9dbf0b967b 100644
--- a/cpukit/include/rtems/confdefs/inittask.h
+++ b/cpukit/include/rtems/confdefs/inittask.h
@@ -46,6 +46,10 @@
 
 #ifdef CONFIGURE_INIT
 
+#define _CONFIGURE_ASSERT_NOT_NULL( _type, _value ) \
+  ( ( _value ) != NULL ? ( _value ) : \
+( _type ) sizeof( int[ ( _value ) != NULL ? 1 : -1 ] ) )
+
 #ifdef CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
 #include 
@@ -94,8 +98,8 @@ extern "C" {
 #endif
 
 /*
- * Ignore the following warnings from g++ and clang in the static assertion
- * below:
+ * Ignore the following warnings from g++ and clang in the uses of
+ * _CONFIGURE_ASSERT_NOT_NULL() below:
  *
  * warning: the address of 'void Init()' will never be NULL [-Waddress]
  *
@@ -107,13 +111,6 @@ extern "C" {
 #pragma GCC diagnostic ignored "-Wpragmas"
 #pragma GCC diagnostic ignored "-Wtautological-pointer-compare"
 
-RTEMS_STATIC_ASSERT(
-  CONFIGURE_INIT_TASK_ENTRY_POINT != NULL,
-  CONFIGURE_INIT_TASK_ENTRY_POINT_MUST_NOT_BE_NULL
-);
-
-#pragma GCC diagnostic pop
-
 #ifdef CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE
 
 #ifdef CONFIGURE_INIT_TASK_STACK_SIZE
@@ -139,7 +136,10 @@ const RTEMS_tasks_User_task_config 
_RTEMS_tasks_User_task_config = {
 CONFIGURE_INIT_TASK_INITIAL_MODES,
 CONFIGURE_INIT_TASK_ATTRIBUTES,
   },
-  CONFIGURE_INIT_TASK_ENTRY_POINT,
+  _CONFIGURE_ASSERT_NOT_NULL(
+rtems_task_entry,
+CONFIGURE_INIT_TASK_ENTRY_POINT
+  ),
   CONFIGURE_INIT_TASK_ARGUMENTS
 };
 
@@ -167,7 +167,10 @@ const rtems_initialization_tasks_table 
_RTEMS_tasks_User_task_table = {
   CONFIGURE_INIT_TASK_STACK_SIZE,
   CONFIGURE_INIT_TASK_PRIORITY,
   CONFIGURE_INIT_TASK_ATTRIBUTES,
-  CONFIGURE_INIT_TASK_ENTRY_POINT,
+  _CONFIGURE_ASSERT_NOT_NULL(
+rtems_task_entry,
+CONFIGURE_INIT_TASK_ENTRY_POINT
+  ),
   CONFIGURE_INIT_TASK_INITIAL_MODES,
   CONFIGURE_INIT_TASK_ARGUMENTS
 };
@@ -180,6 +183,8 @@ RTEMS_SYSINIT_ITEM(
 
 #endif /* CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE */
 
+#pragma GCC diagnostic pop
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/cpukit/include/rtems/confdefs/wkspace.h 
b/cpukit/include/rtems/confdefs/wkspace.h
index 39014d7f1d..eac4bdb4bd 100644
--- a/cpukit/include/rtems/confdefs/wkspace.h
+++ b/cpukit/include/rtems/confdefs/wkspace.h
@@ -139,8 +139,8 @@ const uintptr_t _Stack_Space_size = 
_CONFIGURE_STACK_SPACE_SIZE;
 #if defined(CONFIGURE_TASK_STACK_ALLOCATOR) \
   && defined(CONFIGURE_TASK_STACK_DEALLOCATOR)
   /*
-   * Ignore the following warnings from g++ and clang in the static assertions
-   * below:
+   * Ignore the following warnings from g++ and clang in the uses of
+   * _CONFIGURE_ASSERT_NOT_NULL() below:
*
* warning: the address of 'f()' will never be NULL [-Waddress]
*
@@ -159,13 +159,11 @@ const uintptr_t _Stack_Space_size = 
_CONFIGURE_STACK_SPACE_SIZE;
   #endif
 
   #ifdef CONFIGURE_TASK_STACK_ALLOCATOR_INIT
-RTEMS_STATIC_ASSERT(
-  CONFIGURE_TASK_STACK_ALLOCATOR_INIT != NULL,
-  CONFIGURE_TASK_STACK_ALLOCATOR_INIT_MUST_NOT_BE_NULL
-);
-
 const Stack_Allocator_initialize _Stack_Allocator_initialize =
-  CONFIGURE_TASK_STACK_ALLOCATOR_INIT;
+  _CONFIGURE_ASSERT_NOT_NULL(
+Stack_Allocator_initialize,
+CONFIGURE_TASK_STACK_ALLOCATOR_INIT
+  );
 
 RTEMS_SYSINIT_ITEM(
   _Stack_Allocator_do_initialize,
@@ -174,21 +172,21 @@ const uintptr_t _Stack_Space_size = 
_CONFIGURE_STACK_SPACE_SIZE;
 );
   #endif
 
-  RTEMS_STATIC_ASSERT(
-CONFIGURE_TASK_STACK_ALLOCATOR != NULL,
-CONFIGURE_TASK_STACK_ALLOCATOR_MUST_NOT_BE_NULL
-  );
+  Stack_Allocator_allocate CONFIGURE_TASK_STACK_ALLOCATOR_MUST_NOT_BE_NULL;
 
   const Stack_Allocator_allocate _Stack_Allocator_allocate =
-CONFIGURE_TASK_STACK_ALLOCATOR;
+_CONFIGURE_ASSERT_NOT_NULL(
+  Stack_Allocator_allocate,
+  

Re: CMake support

[Robin Müller]

Hi,

There seems to be positive feedback, thanks for that.

I can adapt the naming to be more consistent with your system.
My system is currently assuming that the RTEMS tools and the BSP are both
located at RTEMS_INST
I guess the first command:

cmake -DPREFIX=/install-point -DRTEMS_BSP=arm/stm32h7

Would have the purpose to install the BSP itself? Right now, I also used
the tools path to autodetermine the RTEMS version
if the version is not supplied manually.cmake by extracting the last number
in the supplied RTEMS_INST path.

I have not really thought about the install process yet, I simply built the
binary in a separate folder out of source like normally done in CMake.
But this should generally be possible, CMake has an install command as well
and the install location can be set using CMAKE_INSTALL_PREFIX

Is it possible to get the pkgconfig files without building the BSPs? That
would be good so more hardware configurations can be added without having
to build every BSP.

Kind Regards
Robin

On Fri, 11 Dec 2020 at 10:59, Stanislav Pankevich 
wrote:

> Hi all,
>
> > I was wondering whether CMake support or an example is available or
> will be added in the future. We are using a framework which has different
> abstraction layers for OSes like (embedded) Linux, RTEMS and FreeRTOS, but
> we would like to use the same build system to build applications and right
> now CMake is our favourite because other tools like the Catch2 test
> framework are also built with CMake and there is a lot more documentation
> available for CMake.
>
> I would like to share our (PTS GmbH, Berlin) experience of using CMake
> with RTEMS. Our case is similar to that of Robin Müller's and our own
> software is all CMake-based. An additional advantage for using CMake for us
> is that the NASA cFS framework has recently switched to CMake so it is much
> easier to integrate it into the existing CMake tree. Another integration
> exercise that we had done before was to build RTEMS and DLR Outpost with
> CMake and that was also quite straightforward in spite of the fact the DLR
> Outpost didn't have a CMake layer.
>
> ~1 year ago we have captured all the RTEMS compilation and linking
> commands done by Autoconf for building the ARM-based BSP and converted them
> into CMakeLists.txt files. At that time, we didn't know how exactly the
> existing build system worked, so we were very careful and created many
> CMakeLists files, one for a folder (example: cpukit/libmisc/cpuuse or our
> own BSP folder). Our setup in the end is not 3 files but 60 files but the
> idea is the same: configs are collected in a few files, the rest are simply
> assigning source files to object/library targets. No changes are made to
> RTEMS source or build files. Instead, we keep all CMake scripts in a
> separate folder called: rtems-cmake-integration.
>
> One of the problems we see with this approach is updating to newer
> versions of RTEMS. If the CMake files do not co-exist with the RTEMS
> development tree, then it might be a manual exercise every time to make
> sure that the CMake integration layer always reflects what the developers
> of RTEMS intend it to be. Having this said, our 1-year-old CMake setup has
> been very stable so far, so we might as well stick with it for the time
> being.
>
> Having this said, I would like to avoid pushing the CMake-way of doing
> things as a better way. Instead, I could contribute feedback to Robin's
> work here: https://github.com/rmspacefish/rtems-cmake. For example, I
> could do the exercise of using his Just 3 files to see if our embedded
> target would compile and run. No hard promises about the time frames though
> until the Christmas holidays :)
>
> Thank you for your attention.
>
> On Fri, Dec 11, 2020 at 1:15 AM Joel Sherrill  wrote:
>
>>
>>
>> On Thu, Dec 10, 2020 at 5:58 PM Chris Johns  wrote:
>>
>>> On 11/12/20 8:51 am, Robin Müller wrote:
>>> > Hello,
>>> >
>>> > I created a repository on github for the first version of what a CMake
>>> support
>>> > for RTEMS might look like:
>>> >
>>> > https://github.com/rmspacefish/rtems-cmake
>>> > 
>>> >
>>>
>>> Awesome and thanks. :)
>>>
>>
>> Agreed. Bear with us being picky. We want things to be as
>> consistent as possible across BSPs, architectures, RTEMS versions,
>> and (hopefully) build systems.
>>
>>
>>> > I tried to extract generic components like determining library paths
>>> into
>>> > functions  (RTEMSGeneric.cmake)
>>> > and there is a hardware specific file where flags for specific
>>> > BSPs/Architectures can be set (RTEMSHardware.cmake).
>>> >
>>> > I was able to compile both the hello project and my STM32 blinky
>>> project with
>>> > really similar and short CMake files which simply call
>>> rtems_general_config.
>>> > with a simple command like
>>> >
>>> > cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=arm/stm32h7
>>>
>>> Would it be possible to align the naming to be consistent with the names
>>> we
>>> currently 

RE: [PATCH v2 0/1] xilinx_zynq: Enable support for 4kiB MMU pages

[Jan.Sommer]

Could someone please push these changes?
I think this is the last patchset from me which is open.

Cheers,

Jan

> -Original Message-
> From: Sommer, Jan
> Sent: Friday, November 27, 2020 2:43 PM
> To: devel@rtems.org
> Cc: Sommer, Jan 
> Subject: [PATCH v2 0/1] xilinx_zynq: Enable support for 4kiB MMU pages
> 
> Changes in v2:
> - Disable the option by default for xilinx_zynq (keep enabled for
>   realview)
> - Created corresponding ticket: https://devel.rtems.org/ticket/4192
> 
> 
> Jan Sommer (1):
>   bsp/xilinx_zynq: Enable support for 4kiB MMU pages
> 
>  c/src/lib/libbsp/arm/xilinx-zynq/configure.ac |  4 
>  spec/build/bsps/arm/optmmusmallpages.yml  | 17 +++--
>  spec/build/bsps/arm/xilinx-zynq/grp.yml   |  2 +-
>  3 files changed, 20 insertions(+), 3 deletions(-)
> 
> --
> 2.17.1

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

Re: CMake support

[Stanislav Pankevich]

Hi all,

> I was wondering whether CMake support or an example is available or will
be added in the future. We are using a framework which has different
abstraction layers for OSes like (embedded) Linux, RTEMS and FreeRTOS, but
we would like to use the same build system to build applications and right
now CMake is our favourite because other tools like the Catch2 test
framework are also built with CMake and there is a lot more documentation
available for CMake.

I would like to share our (PTS GmbH, Berlin) experience of using CMake with
RTEMS. Our case is similar to that of Robin Müller's and our own software
is all CMake-based. An additional advantage for using CMake for us is that
the NASA cFS framework has recently switched to CMake so it is much easier
to integrate it into the existing CMake tree. Another integration exercise
that we had done before was to build RTEMS and DLR Outpost with CMake and
that was also quite straightforward in spite of the fact the DLR Outpost
didn't have a CMake layer.

~1 year ago we have captured all the RTEMS compilation and linking commands
done by Autoconf for building the ARM-based BSP and converted them into
CMakeLists.txt files. At that time, we didn't know how exactly the existing
build system worked, so we were very careful and created many CMakeLists
files, one for a folder (example: cpukit/libmisc/cpuuse or our own BSP
folder). Our setup in the end is not 3 files but 60 files but the idea is
the same: configs are collected in a few files, the rest are simply
assigning source files to object/library targets. No changes are made to
RTEMS source or build files. Instead, we keep all CMake scripts in a
separate folder called: rtems-cmake-integration.

One of the problems we see with this approach is updating to newer versions
of RTEMS. If the CMake files do not co-exist with the RTEMS development
tree, then it might be a manual exercise every time to make sure that the
CMake integration layer always reflects what the developers of RTEMS intend
it to be. Having this said, our 1-year-old CMake setup has been very stable
so far, so we might as well stick with it for the time being.

Having this said, I would like to avoid pushing the CMake-way of doing
things as a better way. Instead, I could contribute feedback to Robin's
work here: https://github.com/rmspacefish/rtems-cmake. For example, I could
do the exercise of using his Just 3 files to see if our embedded target
would compile and run. No hard promises about the time frames though until
the Christmas holidays :)

Thank you for your attention.

On Fri, Dec 11, 2020 at 1:15 AM Joel Sherrill  wrote:

>
>
> On Thu, Dec 10, 2020 at 5:58 PM Chris Johns  wrote:
>
>> On 11/12/20 8:51 am, Robin Müller wrote:
>> > Hello,
>> >
>> > I created a repository on github for the first version of what a CMake
>> support
>> > for RTEMS might look like:
>> >
>> > https://github.com/rmspacefish/rtems-cmake
>> > 
>> >
>>
>> Awesome and thanks. :)
>>
>
> Agreed. Bear with us being picky. We want things to be as
> consistent as possible across BSPs, architectures, RTEMS versions,
> and (hopefully) build systems.
>
>
>> > I tried to extract generic components like determining library paths
>> into
>> > functions  (RTEMSGeneric.cmake)
>> > and there is a hardware specific file where flags for specific
>> > BSPs/Architectures can be set (RTEMSHardware.cmake).
>> >
>> > I was able to compile both the hello project and my STM32 blinky
>> project with
>> > really similar and short CMake files which simply call
>> rtems_general_config.
>> > with a simple command like
>> >
>> > cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=arm/stm32h7
>>
>> Would it be possible to align the naming to be consistent with the names
>> we
>> currently have? We use --rtems-tools for the path to the tools so would
>> RTEMS_TOOLS work?
>>
>> We also provide the ability to specify where RTEMS (the RTEMS BSP) is
>> installed.
>> In some configurations we have a prefix, where the application or library
>> being
>> built are installed plus the RTEMS tools path and the RTEMS BSP path.
>> They can
>> all be the same or different.
>>
>> I am not sure what cmake does for the prefix so I will use PREFIX in my
>> examples:
>>
>>  cmake -DPREFIX=/install-point -DRTEMS_BSP=arm/stm32h7
>>
>> Internally RTEMS_TOOLS and RTEMS would be set to PREFIX.
>>
>>  cmake -DPREFIX=/install-point -DRTEMS_TOOLS=/tools-path
>> -DRTEMS_BSP=arm/stm32h7
>>
>> RTEMS_TOOLS is defined and RTEMS is set to RTEMS_TOOLS.
>>
>> Finally we can have:
>>
>>  cmake -DPREFIX=/install-path \
>>-DRTEMS_TOOLS=/tools-path
>>-DRTEMS=/bsp-path \
>>-DRTEMS_BSP=arm/stm32h7
>>
>> All are left as defined on the command line.
>>
>> We have this separation so you can build a set of tools and build
>> different
>> branches of RTEMS and then different branches of the application or
>> library for
>> any of those combinations. A typical user will use the first or