Re: Applying an operation to a set of threads in RTEMS

2020-07-03 Thread Utkarsh Rai
On Sat, Jul 4, 2020 at 1:13 AM  wrote:

> This thought is intended to be evaluated, not adopted.  What I meant was I
> think you have a "bitmask" of threads that need access to a stack that is
> similar to a "bitmask" of threads/processes that may be blocked in select.
> The select-mask is a major focus across operating systems.  That's why I
> thought that if you consider it to be equivalent you should use that
> interface.
>
>
Oh, that makes more sense. Thank you for the clarification!

> On Jul 3, 2020, at 08:42 , dufa...@hda.com wrote:
> >
> > My thought is that it matches what is needed and is expected to be
> optimized.
> >
> >> On Jul 3, 2020, at 24:37 , Utkarsh Rai  wrote:
> >>
> >>
> >>
> >> On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault  wrote:
> >> I finally have gotten to reviewing Utkarsh's work in GSOC.  One item
> that I don't like is that there is a linked list management of the threads
> that have access to the stack.
> >> I think this access is similar to the file descriptors that are blocked
> in a select call.  On a given architecture I don't know exactly how many
> file descriptors I can block, I don't know exactly what the FD_SET macro
> does, but I have access to multiple file descriptors through the FD_*
> macros.
> >>
> >>
> >> Hello, thank you for the feedback. If I understand your suggestion
> correctly, we can specify a file descriptor set 'fd_set' and then register
> the stack attributes to this set, and then check for the 'current stack'
> through select() and FD_ISSET()?
> >>
> >> Using FD_SET and friends for specifying thread access could be a good
> model to specify which threads need access to which thread.
> >>
> >> My question is,  what benefit do we get by using FD_SET and friends?
> Ultimately we will have to iterate through the set to check for the
> 'current stack'.
> >>
> >> However, it won't scale infinitely.  Linked lists won't scale
> infinitely in real-time either.
> >>
> >> An optimization that I had in mind was to use the LRU model. This way
> we can mark the stack attributes of the last thread as 'not current'
> without iterating through the list or the set.
> >>
> >> Peter
> >> -
> >> Peter Dufault
> >> HD Associates, Inc.  Software and System Engineering
> >>
> >> This email is delivered through the public internet using protocols
> subject to interception and tampering.
> >>
> >
> > Peter
> > -
> > Peter Dufault
> > HD Associates, Inc.  Software and System Engineering
> >
> > This email is delivered through the public internet using protocols
> subject to interception and tampering.
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
>
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: ARM GCC machine options for RTEMS 6

2020-07-03 Thread Chris Johns
On 3/7/20 5:06 pm, Sebastian Huber wrote:
> Hello,
> 
> someone from ARM changed the machine options used to build the RTEMS multilibs
> some time ago (I think GCC 8):

Was a reason given?

> 
> arm-rtems6-gcc -print-multi-lib -march=armv4t
> .;
> thumb;@mthumb
> armv5te+fp/hard;@march=armv5te+fp@mfloat-abi=hard
> thumb/armv6-m;@mthumb@march=armv6-m
> thumb/armv7-a;@mthumb@march=armv7-a
> thumb/armv7-r;@mthumb@march=armv7-r
> thumb/cortex-m3;@mthumb@mcpu=cortex-m3
> thumb/cortex-m4+nofp;@mthumb@mcpu=cortex-m4+nofp
> thumb/armv7-a+simd/hard;@mthumb@march=armv7-a+simd@mfloat-abi=hard
> thumb/armv7-r+fp/hard;@mthumb@march=armv7-r+fp@mfloat-abi=hard
> thumb/cortex-m4/hard;@mthumb@mcpu=cortex-m4@mfloat-abi=hard
> thumb/cortex-m7/hard;@mthumb@mcpu=cortex-m7@mfloat-abi=hard
> eb/thumb/armv7-r;@mbig-endian@mthumb@march=armv7-r
> eb/thumb/armv7-r+fp/hard;@mbig-endian@mthumb@march=armv7-r+fp@mfloat-abi=hard
> 
> It seems that our current machine options still map to the right multilib:
> 
> arm-rtems6-gcc -print-multi-directory -march=armv7-a -mthumb -mfpu=neon
> -mfloat-abi=hard -mtune=cortex-a9
> thumb/armv7-a+simd/hard
> 
> arm-rtems6-gcc -print-multi-directory -mthumb -mcpu=cortex-m4 
> -mfpu=fpv4-sp-d16
> -mfloat-abi=hard
> thumb/cortex-m4/hard
> 
> arm-rtems6-gcc -print-multi-directory -march=armv7-r -mthumb -mbig-endian
> eb/thumb/armv7-r
> 
> arm-rtems6-gcc -print-multi-directory -march=armv7-r -mthumb -mbig-endian
> -mfpu=vfpv3-d16 -mfloat-abi=hard
> eb/thumb/armv7-r+fp/hard
> 
> Should we change the options to match the ones given in the multilib 
> definition
> or should we keep the current options? If we change the options, then we can 
> no
> longer build with GCC 7.

Would we need to build gcc 7 for RTEMS 6?

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


Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-03 Thread Mritunjay Sharma
[UPDATE]: After using --enable-posix, the 'make' in epics-base worked
successfully.
With all of yours support, there are no errors. Everything seems to be
in order.

Heinz, as you suggested, now I have built EPICS with RTEMS 4.10 for pc-386
and as advised that after this
we can take care of RTEMS5 (or 6?) and libbsd as I have learnt now how to
build EPICS and I think we can develop
a first rsb-set for it.

Please advise on what to begin with next.

Thanks
Mritunjay

On Sat, Jul 4, 2020 at 3:02 AM Mritunjay Sharma <
mritunjaysharma...@gmail.com> wrote:

> Thank you so much Gedare, I will do it and revert back to you.
>
> Thanks
> Mritunjay
>
> On Sat, Jul 4, 2020 at 3:01 AM Gedare Bloom  wrote:
>
>> On Fri, Jul 3, 2020 at 3:07 PM Mritunjay Sharma
>>  wrote:
>> >
>> >
>> >
>> > On Fri, Jul 3, 2020 at 10:53 PM Mritunjay Sharma <
>> mritunjaysharma...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> 
>> >> From: Gedare Bloom 
>> >> Sent: Friday, July 3, 2020 9:42 PM
>> >> To: Mritunjay Sharma
>> >> Cc: Heinz Junkes; Chris Johns; RTEMS Devel
>> >> Subject: Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5
>> >>
>> >> On Fri, Jul 3, 2020 at 9:17 AM Mritunjay Sharma
>> >>  wrote:
>> >> >
>> >> > Hello Heinz and everyone,
>> >> >
>> >> > Thank you so much, with this email, I will try to clear all the
>> things, and what is the status for now.
>> >> >
>> >> > First. let me tell you the current status: Vijay helped me last
>> night in an offlist discussion to clear the confusions which
>> >> > I was having (I will mention them below) due to which I was able to
>> build and install RTEMS 4.10 for pc386 successfully.
>> >> > With that, all my previous errors were resolved. Below is the detail
>> of all the steps, I followed.
>> >> >
>> >> > Let me tell that my development environment was earlier set up for
>> RTEMS5. For building EPICS with RTEMS,
>> >> > I thought it will be right to first build RTEMS 4.10 for pc386.
>> >> >
>> >> > In order to do that, I made the directory
>> >> >
>> >> > i) $HOME/development/rtems_dev
>> >> > ii) I extracted rtems-4.10.2 from here
>> https://ftp.rtems.org/pub/rtems/releases/4.10/4.10.2/
>> >> > iii)I created another directory rtems_dev/src
>> >> > iv)Inside src, I cloned rsb and moved to 4.10 branch.
>> >> > v) After performing checks, I entered to rsb/rtems and used this
>> command:
>> >> > '../source-builder/sb-set-builder
>> --prefix=/home/mritunjay/development/rtems_dev/rtems-4.10.2 4.10/rtems-i386'
>> >> > Even though the build completed successfully, this was the point
>> where I made the error. I used the RTEMS source as the prefix which
>> >> > was causing all the problems.
>> >> > vi) After the discussion with Vijay and getting cleared, I deleted
>> everything except the RTEMS RSB and restarted the process with prefix and
>> source
>> >> > different this time and rebuilt the compiler tools using RSB.
>> >> > vii) Now the directory structure under $HOME/development/rtems_dev/
>> looked like:
>> >> >   | rtems-4.10.2
>> >> >   | 4.10
>> >> >   | src/rsb
>> >> >   | kernel/pc386
>> >> > I also used this command: "export
>> PATH=$HOME/development/rtems_dev/4.10/bin:$PATH"
>> >> > vi) Then I went to rtems_dev/rtems-4.10.2 and used this command:
>> >> > "./bootstrap -c &&
>> $HOME/development/rtems_dev/src/rsb/source-builder/sb-bootstrap"
>> >> > vi) After this I went insid directory
>> $HOME/development/rtems_dev/kernel/pc-386
>> >> > vii) Inside pc-386, I used the following command:
>> >> > ''$HOME/development/rtems_dev/rtems-4.10.2/configure
>> --target=i386-rtems4.10 --disable-posix  --enable-rtemsbsp=pc386
>> --enable-tests=samples --prefix=/home/development/rtems_dev/rtems-4.10.2
>> --enable-cxx"
>>
>> You need to --enable-posix
>>
>> >> > viii) Then I entered the make command which ran successfully and the
>> make install was also successful.
>> >> >
>> >> > So all the errors were resolved and I moved on to build EPICS now
>> for RTEMS 4.10.
>> >> > I also used this command:
>> >> > '''export
>> RTEMS_MAKEFILE_PATH=$HOME/development/rtems_dev/4.10/i386-rtems4.10/pc386''
>> >> > Location of epics-base in my system is as follows:
>> >> > "$HOME/development/EPICS/epics-base"
>> >> >
>> >> > After this, I followed the tutorial you sent to build EPICS for
>> rterms-4.10 for pc-386 which is:
>> >> >>
>> >> >> Very roughly:
>> >> >> git clone —recursive epics-base
>> >> >>
>> >> >> in epics-base/configure/CONFIG_SITE
>> >> >> set
>> >> >> CROSS_COMPILER_TARGET_ARCHS=
>> >> >
>> >> >What I entered:
>> >> >CROSS_COMPILER_TARGET_ARCHS=  RTEMS-pc386
>> >> >>
>> >> >> e.g. RTEMS-pc386
>> >> >> or RTEMS-xilinx_zynq_a9_qemu
>> >> >>
>> >> >> in epics-base/configure/os there must be a file for the target used,
>> >> >> e.g.
>> >> >> CONFIG.Common.RTEMS-xilinx_zynq_a9_qemu
>> >> >> or
>> >> >> CONFIG.Common.RTEMS-pc386
>> >> >
>> >> > Checked.  CONFIG.Common.RTEMS-pc386 was there
>> >> >>
>> >> >>
>> >> >> Then you have to set in 

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-03 Thread Mritunjay Sharma
Thank you so much Gedare, I will do it and revert back to you.

Thanks
Mritunjay

On Sat, Jul 4, 2020 at 3:01 AM Gedare Bloom  wrote:

> On Fri, Jul 3, 2020 at 3:07 PM Mritunjay Sharma
>  wrote:
> >
> >
> >
> > On Fri, Jul 3, 2020 at 10:53 PM Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
> >>
> >>
> >>
> >> 
> >> From: Gedare Bloom 
> >> Sent: Friday, July 3, 2020 9:42 PM
> >> To: Mritunjay Sharma
> >> Cc: Heinz Junkes; Chris Johns; RTEMS Devel
> >> Subject: Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5
> >>
> >> On Fri, Jul 3, 2020 at 9:17 AM Mritunjay Sharma
> >>  wrote:
> >> >
> >> > Hello Heinz and everyone,
> >> >
> >> > Thank you so much, with this email, I will try to clear all the
> things, and what is the status for now.
> >> >
> >> > First. let me tell you the current status: Vijay helped me last night
> in an offlist discussion to clear the confusions which
> >> > I was having (I will mention them below) due to which I was able to
> build and install RTEMS 4.10 for pc386 successfully.
> >> > With that, all my previous errors were resolved. Below is the detail
> of all the steps, I followed.
> >> >
> >> > Let me tell that my development environment was earlier set up for
> RTEMS5. For building EPICS with RTEMS,
> >> > I thought it will be right to first build RTEMS 4.10 for pc386.
> >> >
> >> > In order to do that, I made the directory
> >> >
> >> > i) $HOME/development/rtems_dev
> >> > ii) I extracted rtems-4.10.2 from here
> https://ftp.rtems.org/pub/rtems/releases/4.10/4.10.2/
> >> > iii)I created another directory rtems_dev/src
> >> > iv)Inside src, I cloned rsb and moved to 4.10 branch.
> >> > v) After performing checks, I entered to rsb/rtems and used this
> command:
> >> > '../source-builder/sb-set-builder
> --prefix=/home/mritunjay/development/rtems_dev/rtems-4.10.2 4.10/rtems-i386'
> >> > Even though the build completed successfully, this was the point
> where I made the error. I used the RTEMS source as the prefix which
> >> > was causing all the problems.
> >> > vi) After the discussion with Vijay and getting cleared, I deleted
> everything except the RTEMS RSB and restarted the process with prefix and
> source
> >> > different this time and rebuilt the compiler tools using RSB.
> >> > vii) Now the directory structure under $HOME/development/rtems_dev/
> looked like:
> >> >   | rtems-4.10.2
> >> >   | 4.10
> >> >   | src/rsb
> >> >   | kernel/pc386
> >> > I also used this command: "export
> PATH=$HOME/development/rtems_dev/4.10/bin:$PATH"
> >> > vi) Then I went to rtems_dev/rtems-4.10.2 and used this command:
> >> > "./bootstrap -c &&
> $HOME/development/rtems_dev/src/rsb/source-builder/sb-bootstrap"
> >> > vi) After this I went insid directory
> $HOME/development/rtems_dev/kernel/pc-386
> >> > vii) Inside pc-386, I used the following command:
> >> > ''$HOME/development/rtems_dev/rtems-4.10.2/configure
> --target=i386-rtems4.10 --disable-posix  --enable-rtemsbsp=pc386
> --enable-tests=samples --prefix=/home/development/rtems_dev/rtems-4.10.2
> --enable-cxx"
>
> You need to --enable-posix
>
> >> > viii) Then I entered the make command which ran successfully and the
> make install was also successful.
> >> >
> >> > So all the errors were resolved and I moved on to build EPICS now for
> RTEMS 4.10.
> >> > I also used this command:
> >> > '''export
> RTEMS_MAKEFILE_PATH=$HOME/development/rtems_dev/4.10/i386-rtems4.10/pc386''
> >> > Location of epics-base in my system is as follows:
> >> > "$HOME/development/EPICS/epics-base"
> >> >
> >> > After this, I followed the tutorial you sent to build EPICS for
> rterms-4.10 for pc-386 which is:
> >> >>
> >> >> Very roughly:
> >> >> git clone —recursive epics-base
> >> >>
> >> >> in epics-base/configure/CONFIG_SITE
> >> >> set
> >> >> CROSS_COMPILER_TARGET_ARCHS=
> >> >
> >> >What I entered:
> >> >CROSS_COMPILER_TARGET_ARCHS=  RTEMS-pc386
> >> >>
> >> >> e.g. RTEMS-pc386
> >> >> or RTEMS-xilinx_zynq_a9_qemu
> >> >>
> >> >> in epics-base/configure/os there must be a file for the target used,
> >> >> e.g.
> >> >> CONFIG.Common.RTEMS-xilinx_zynq_a9_qemu
> >> >> or
> >> >> CONFIG.Common.RTEMS-pc386
> >> >
> >> > Checked.  CONFIG.Common.RTEMS-pc386 was there
> >> >>
> >> >>
> >> >> Then you have to set in configure/os/CONFIG_SITE.Common.RTEMS
> >> >> where to find RTEMS:
> >> >>
> >> >> # Where to find RTEMS
> >> >> #
> >> >> # APS:
> >> >> #RTEMS_VERSION = 4.10.2
> >> >> #RTEMS_BASE = /usr/local/vw/rtems/rtems-$(RTEMS_VERSION)
> >> >
> >> >
> >> > In my system, I entered this:
> >> > #APS
> >> > RTEMS_VERSION = 4.10
> >> > RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)
> >> >
> >> > I followed the above instructions and used the 'make' command.
> >> >
> >> >
> >> > While the earlier errors are resolved, The latest error that I have
> encountered is this after using make command.:
> >> >
> >> > "...Info':
> >> >
> 

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-03 Thread Gedare Bloom
On Fri, Jul 3, 2020 at 3:07 PM Mritunjay Sharma
 wrote:
>
>
>
> On Fri, Jul 3, 2020 at 10:53 PM Mritunjay Sharma 
>  wrote:
>>
>>
>>
>> 
>> From: Gedare Bloom 
>> Sent: Friday, July 3, 2020 9:42 PM
>> To: Mritunjay Sharma
>> Cc: Heinz Junkes; Chris Johns; RTEMS Devel
>> Subject: Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5
>>
>> On Fri, Jul 3, 2020 at 9:17 AM Mritunjay Sharma
>>  wrote:
>> >
>> > Hello Heinz and everyone,
>> >
>> > Thank you so much, with this email, I will try to clear all the things, 
>> > and what is the status for now.
>> >
>> > First. let me tell you the current status: Vijay helped me last night in 
>> > an offlist discussion to clear the confusions which
>> > I was having (I will mention them below) due to which I was able to build 
>> > and install RTEMS 4.10 for pc386 successfully.
>> > With that, all my previous errors were resolved. Below is the detail of 
>> > all the steps, I followed.
>> >
>> > Let me tell that my development environment was earlier set up for RTEMS5. 
>> > For building EPICS with RTEMS,
>> > I thought it will be right to first build RTEMS 4.10 for pc386.
>> >
>> > In order to do that, I made the directory
>> >
>> > i) $HOME/development/rtems_dev
>> > ii) I extracted rtems-4.10.2 from here 
>> > https://ftp.rtems.org/pub/rtems/releases/4.10/4.10.2/
>> > iii)I created another directory rtems_dev/src
>> > iv)Inside src, I cloned rsb and moved to 4.10 branch.
>> > v) After performing checks, I entered to rsb/rtems and used this command:
>> > '../source-builder/sb-set-builder 
>> > --prefix=/home/mritunjay/development/rtems_dev/rtems-4.10.2 
>> > 4.10/rtems-i386'
>> > Even though the build completed successfully, this was the point where I 
>> > made the error. I used the RTEMS source as the prefix which
>> > was causing all the problems.
>> > vi) After the discussion with Vijay and getting cleared, I deleted 
>> > everything except the RTEMS RSB and restarted the process with prefix and 
>> > source
>> > different this time and rebuilt the compiler tools using RSB.
>> > vii) Now the directory structure under $HOME/development/rtems_dev/ looked 
>> > like:
>> >   | rtems-4.10.2
>> >   | 4.10
>> >   | src/rsb
>> >   | kernel/pc386
>> > I also used this command: "export 
>> > PATH=$HOME/development/rtems_dev/4.10/bin:$PATH"
>> > vi) Then I went to rtems_dev/rtems-4.10.2 and used this command:
>> > "./bootstrap -c && 
>> > $HOME/development/rtems_dev/src/rsb/source-builder/sb-bootstrap"
>> > vi) After this I went insid directory 
>> > $HOME/development/rtems_dev/kernel/pc-386
>> > vii) Inside pc-386, I used the following command:
>> > ''$HOME/development/rtems_dev/rtems-4.10.2/configure 
>> > --target=i386-rtems4.10 --disable-posix  --enable-rtemsbsp=pc386 
>> > --enable-tests=samples --prefix=/home/development/rtems_dev/rtems-4.10.2 
>> > --enable-cxx"

You need to --enable-posix

>> > viii) Then I entered the make command which ran successfully and the make 
>> > install was also successful.
>> >
>> > So all the errors were resolved and I moved on to build EPICS now for 
>> > RTEMS 4.10.
>> > I also used this command:
>> > '''export 
>> > RTEMS_MAKEFILE_PATH=$HOME/development/rtems_dev/4.10/i386-rtems4.10/pc386''
>> > Location of epics-base in my system is as follows:
>> > "$HOME/development/EPICS/epics-base"
>> >
>> > After this, I followed the tutorial you sent to build EPICS for 
>> > rterms-4.10 for pc-386 which is:
>> >>
>> >> Very roughly:
>> >> git clone —recursive epics-base
>> >>
>> >> in epics-base/configure/CONFIG_SITE
>> >> set
>> >> CROSS_COMPILER_TARGET_ARCHS=
>> >
>> >What I entered:
>> >CROSS_COMPILER_TARGET_ARCHS=  RTEMS-pc386
>> >>
>> >> e.g. RTEMS-pc386
>> >> or RTEMS-xilinx_zynq_a9_qemu
>> >>
>> >> in epics-base/configure/os there must be a file for the target used,
>> >> e.g.
>> >> CONFIG.Common.RTEMS-xilinx_zynq_a9_qemu
>> >> or
>> >> CONFIG.Common.RTEMS-pc386
>> >
>> > Checked.  CONFIG.Common.RTEMS-pc386 was there
>> >>
>> >>
>> >> Then you have to set in configure/os/CONFIG_SITE.Common.RTEMS
>> >> where to find RTEMS:
>> >>
>> >> # Where to find RTEMS
>> >> #
>> >> # APS:
>> >> #RTEMS_VERSION = 4.10.2
>> >> #RTEMS_BASE = /usr/local/vw/rtems/rtems-$(RTEMS_VERSION)
>> >
>> >
>> > In my system, I entered this:
>> > #APS
>> > RTEMS_VERSION = 4.10
>> > RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)
>> >
>> > I followed the above instructions and used the 'make' command.
>> >
>> >
>> > While the earlier errors are resolved, The latest error that I have 
>> > encountered is this after using make command.:
>> >
>> > "...Info':
>> > /home/mritunjay/development/EPICS/epics-base/modules/libcom/src/O.RTEMS-pc386/../osi/os/RTEMS/osdThread.c:747:
>> >  undefined reference to `pthread_getschedparam'
>> > collect2: ld returned 1 exit status
>> > ../../../../configure/RULES_BUILD:212: recipe for target 
>> > 'libComTestHarness' failed
>> > make[4]: *** 

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-03 Thread Mritunjay Sharma
On Fri, Jul 3, 2020 at 10:53 PM Mritunjay Sharma <
mritunjaysharma...@gmail.com> wrote:

>
>
> --
> *From:* Gedare Bloom 
> *Sent:* Friday, July 3, 2020 9:42 PM
> *To:* Mritunjay Sharma
> *Cc:* Heinz Junkes; Chris Johns; RTEMS Devel
> *Subject:* Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5
>
> On Fri, Jul 3, 2020 at 9:17 AM Mritunjay Sharma
>  wrote:
> >
> > Hello Heinz and everyone,
> >
> > Thank you so much, with this email, I will try to clear all the things,
> and what is the status for now.
> >
> > First. let me tell you the current status: Vijay helped me last night in
> an offlist discussion to clear the confusions which
> > I was having (I will mention them below) due to which I was able to
> build and install RTEMS 4.10 for pc386 successfully.
> > With that, all my previous errors were resolved. Below is the detail of
> all the steps, I followed.
> >
> > Let me tell that my development environment was earlier set up for
> RTEMS5. For building EPICS with RTEMS,
> > I thought it will be right to first build RTEMS 4.10 for pc386.
> >
> > In order to do that, I made the directory
> >
> > i) $HOME/development/rtems_dev
> > ii) I extracted rtems-4.10.2 from here
> https://ftp.rtems.org/pub/rtems/releases/4.10/4.10.2/
> > iii)I created another directory rtems_dev/src
> > iv)Inside src, I cloned rsb and moved to 4.10 branch.
> > v) After performing checks, I entered to rsb/rtems and used this command:
> > '../source-builder/sb-set-builder
> --prefix=/home/mritunjay/development/rtems_dev/rtems-4.10.2 4.10/rtems-i386'
> > Even though the build completed successfully, this was the point where I
> made the error. I used the RTEMS source as the prefix which
> > was causing all the problems.
> > vi) After the discussion with Vijay and getting cleared, I deleted
> everything except the RTEMS RSB and restarted the process with prefix and
> source
> > different this time and rebuilt the compiler tools using RSB.
> > vii) Now the directory structure under $HOME/development/rtems_dev/
> looked like:
> >   | rtems-4.10.2
> >   | 4.10
> >   | src/rsb
> >   | kernel/pc386
> > I also used this command: "export
> PATH=$HOME/development/rtems_dev/4.10/bin:$PATH"
> > vi) Then I went to rtems_dev/rtems-4.10.2 and used this command:
> > "./bootstrap -c &&
> $HOME/development/rtems_dev/src/rsb/source-builder/sb-bootstrap"
> > vi) After this I went insid directory
> $HOME/development/rtems_dev/kernel/pc-386
> > vii) Inside pc-386, I used the following command:
> > ''$HOME/development/rtems_dev/rtems-4.10.2/configure
> --target=i386-rtems4.10 --disable-posix  --enable-rtemsbsp=pc386
> --enable-tests=samples --prefix=/home/development/rtems_dev/rtems-4.10.2
> --enable-cxx"
> > viii) Then I entered the make command which ran successfully and the
> make install was also successful.
> >
> > So all the errors were resolved and I moved on to build EPICS now for
> RTEMS 4.10.
> > I also used this command:
> > '''export
> RTEMS_MAKEFILE_PATH=$HOME/development/rtems_dev/4.10/i386-rtems4.10/pc386''
> > Location of epics-base in my system is as follows:
> > "$HOME/development/EPICS/epics-base"
> >
> > After this, I followed the tutorial you sent to build EPICS for
> rterms-4.10 for pc-386 which is:
> >>
> >> Very roughly:
> >> git clone —recursive epics-base
> >>
> >> in epics-base/configure/CONFIG_SITE
> >> set
> >> CROSS_COMPILER_TARGET_ARCHS=
> >
> >What I entered:
> >CROSS_COMPILER_TARGET_ARCHS=  RTEMS-pc386
> >>
> >> e.g. RTEMS-pc386
> >> or RTEMS-xilinx_zynq_a9_qemu
> >>
> >> in epics-base/configure/os there must be a file for the target used,
> >> e.g.
> >> CONFIG.Common.RTEMS-xilinx_zynq_a9_qemu
> >> or
> >> CONFIG.Common.RTEMS-pc386
> >
> > Checked.  CONFIG.Common.RTEMS-pc386 was there
> >>
> >>
> >> Then you have to set in configure/os/CONFIG_SITE.Common.RTEMS
> >> where to find RTEMS:
> >>
> >> # Where to find RTEMS
> >> #
> >> # APS:
> >> #RTEMS_VERSION = 4.10.2
> >> #RTEMS_BASE = /usr/local/vw/rtems/rtems-$(RTEMS_VERSION)
> >
> >
> > In my system, I entered this:
> > #APS
> > RTEMS_VERSION = 4.10
> > RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)
> >
> > I followed the above instructions and used the 'make' command.
> >
> >
> > While the earlier errors are resolved, The latest error that I have
> encountered is this after using make command.:
> >
> > "...Info':
> >
> /home/mritunjay/development/EPICS/epics-base/modules/libcom/src/O.RTEMS-pc386/../osi/os/RTEMS/osdThread.c:747:
> undefined reference to `pthread_getschedparam'
> > collect2: ld returned 1 exit status
> > ../../../../configure/RULES_BUILD:212: recipe for target
> 'libComTestHarness' failed
> > make[4]: *** [libComTestHarness] Error 1
> > make[4]: Leaving directory
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/test/O.RTEMS-pc386'
> > ../../../configure/RULES_ARCHS:58: recipe for target
> 'install.RTEMS-pc386' failed
> > make[3]: *** [install.RTEMS-pc386] 

Application configuration option documentation license change

2020-07-03 Thread Sebastian Huber

Hello,

for your information, I carried out the license change of the 
application configuration options documentation. They are now under a 
dual CC-BY-SA-4.0 or BSD-2-Clause license.


https://git.rtems.org/sebh/rtems-qual.git/commit/?id=c116767b19e109f007d683e477481af67d603816

This allows generation of documentation sources under CC-BY-SA-4.0 
license and Doxygen markup under BSD-2-Clause license.


I work currently on a generation of the Doxygen markup. This allows to 
easily reference configuration options in the Doxygen documentation. For 
example, this can be used to improve documentation for configuration 
defined data structures such as:


/**
 * @brief Registered schedulers.
 *
 * Application provided via .
 *
 * @see _Scheduler_Count.
 */
extern const Scheduler_Control _Scheduler_Table[];

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

Re: [PATCH 2/3] eng: Add build system chapter

2020-07-03 Thread Sebastian Huber

On 03/07/2020 17:09, Gedare Bloom wrote:


On Fri, Jul 3, 2020 at 3:18 AM Sebastian Huber
  wrote:

Update #3818.
---
  eng/build-system.rst | 406 +++
  eng/index.rst|   1 +
  images/eng/bld-bsp.dot   |  33 
  images/eng/bld-bsp.pdf   | Bin 0 -> 15044 bytes
  images/eng/bld-bsp.png   | Bin 0 -> 32435 bytes
  images/eng/bld-bsp2.dot  |  42 
  images/eng/bld-bsp2.pdf  | Bin 0 -> 16314 bytes
  images/eng/bld-bsp2.png  | Bin 0 -> 33936 bytes
  images/eng/bld-deps.dot  |  59 ++
  images/eng/bld-deps.pdf  | Bin 0 -> 18559 bytes
  images/eng/bld-deps.png  | Bin 0 -> 18098 bytes
  images/eng/bld-deps2.dot |  52 +
  images/eng/bld-deps2.pdf | Bin 0 -> 18241 bytes
  images/eng/bld-deps2.png | Bin 0 -> 40695 bytes

Maybe better to add the binary files in a patch first by themselves,
separate from the ascii. Easier to review, merge, etc.

Yes, sorry.



[...]
+Configurable things which depend on the host computer environment such as paths
+to tools are intended to be passed as command line options to the ``waf``
+command line tool.  Configurable things which define what is built and how the
+artefacts are configured are intended to be placed in configuration files that
+can be configuration controlled.  The ``waf`` build script file called
+``wscript`` file should know nothing about the layout of the sources.  What is

file repetitive, can remove one of them from "script file" or "file should"

Yes this sounds awkward.



[...]
+UID Naming Conventions
+==
+
+Use the following patterns for :ref:`UID names `:
+
+abi
+Use the name ``abi`` for BSP ABI flags.

Is this not a prefix, it is unique `abi`?


Yes, it is not a prefix.

find spec -name abi.yml | wc
 84  84    4455




+
+bsp*
+Use the prefix ``bsp`` for base BSPs.
+
+cfg*
+Use the prefix ``cfg`` for ``config.h`` header options.
+
+grp*
+Use the prefix ``grp`` for groups.
+
+lib*
+Use the prefix ``lib`` for libraries.
+
+linkcmds*
+Use the prefix ``linkcmds`` for linker command files.
+
+obj*
+Use the prefix ``obj`` for objects.  Use
+
+* ``objmpci`` for objects which are enabled by ``RTEMS_MULTIPROCESSING``,
+
+* ``objnet`` for objects which are enabled by ``RTEMS_NETWORKING``,
+
+* ``objnetnosmp`` for objects which are enabled by ``RTEMS_NETWORKING`` and
+  not ``RTEMS_SMP``, and
+
+* ``objsmp`` for objects which are enabled by ``RTEMS_SMP``.
+
+opt*
+Use the prefix ``opt`` for options.  Use
+
+* ``optclk*`` for options which have something to do with the clock
+  driver,
+
+* ``optcon*`` for options which have something to do with the console
+  driver,
+
+* ``optirq*`` for options which have something to do with interrupt
+  processing,
+
+* ``opt*mem*`` for options which have something to do with the memory
+  configuration, map, settings, etc., and

Is the * between opt and mem supposed to be there?
I think the name patterns need some rethinking. They originate from the 
Doorstop era which produced quite long path names. Now we can be a bit 
more descriptive. I will send a v2.



+
+* ``optosc*`` for options which have something to do with oscillators.
+
+start
+Use the name ``start`` for BSP start files.

Also is not a prefix?


Yes, also not a prefix:

find spec -name start.yml | wc
 60  60    3244

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

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-03 Thread Mritunjay Sharma



From: Gedare Bloom 
Sent: Friday, July 3, 2020 9:42 PM
To: Mritunjay Sharma
Cc: Heinz Junkes; Chris Johns; RTEMS Devel
Subject: Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

On Fri, Jul 3, 2020 at 9:17 AM Mritunjay Sharma
 wrote:
>
> Hello Heinz and everyone,
>
> Thank you so much, with this email, I will try to clear all the things, and 
> what is the status for now.
>
> First. let me tell you the current status: Vijay helped me last night in an 
> offlist discussion to clear the confusions which
> I was having (I will mention them below) due to which I was able to build and 
> install RTEMS 4.10 for pc386 successfully.
> With that, all my previous errors were resolved. Below is the detail of all 
> the steps, I followed.
>
> Let me tell that my development environment was earlier set up for RTEMS5. 
> For building EPICS with RTEMS,
> I thought it will be right to first build RTEMS 4.10 for pc386.
>
> In order to do that, I made the directory
>
> i) $HOME/development/rtems_dev
> ii) I extracted rtems-4.10.2 from here 
> https://ftp.rtems.org/pub/rtems/releases/4.10/4.10.2/
> iii)I created another directory rtems_dev/src
> iv)Inside src, I cloned rsb and moved to 4.10 branch.
> v) After performing checks, I entered to rsb/rtems and used this command:
> '../source-builder/sb-set-builder 
> --prefix=/home/mritunjay/development/rtems_dev/rtems-4.10.2 4.10/rtems-i386'
> Even though the build completed successfully, this was the point where I made 
> the error. I used the RTEMS source as the prefix which
> was causing all the problems.
> vi) After the discussion with Vijay and getting cleared, I deleted everything 
> except the RTEMS RSB and restarted the process with prefix and source
> different this time and rebuilt the compiler tools using RSB.
> vii) Now the directory structure under $HOME/development/rtems_dev/ looked 
> like:
>   | rtems-4.10.2
>   | 4.10
>   | src/rsb
>   | kernel/pc386
> I also used this command: "export 
> PATH=$HOME/development/rtems_dev/4.10/bin:$PATH"
> vi) Then I went to rtems_dev/rtems-4.10.2 and used this command:
> "./bootstrap -c && 
> $HOME/development/rtems_dev/src/rsb/source-builder/sb-bootstrap"
> vi) After this I went insid directory 
> $HOME/development/rtems_dev/kernel/pc-386
> vii) Inside pc-386, I used the following command:
> ''$HOME/development/rtems_dev/rtems-4.10.2/configure --target=i386-rtems4.10 
> --disable-posix  --enable-rtemsbsp=pc386 --enable-tests=samples 
> --prefix=/home/development/rtems_dev/rtems-4.10.2 --enable-cxx"
> viii) Then I entered the make command which ran successfully and the make 
> install was also successful.
>
> So all the errors were resolved and I moved on to build EPICS now for RTEMS 
> 4.10.
> I also used this command:
> '''export 
> RTEMS_MAKEFILE_PATH=$HOME/development/rtems_dev/4.10/i386-rtems4.10/pc386''
> Location of epics-base in my system is as follows:
> "$HOME/development/EPICS/epics-base"
>
> After this, I followed the tutorial you sent to build EPICS for rterms-4.10 
> for pc-386 which is:
>>
>> Very roughly:
>> git clone —recursive epics-base
>>
>> in epics-base/configure/CONFIG_SITE
>> set
>> CROSS_COMPILER_TARGET_ARCHS=
>
>What I entered:
>CROSS_COMPILER_TARGET_ARCHS=  RTEMS-pc386
>>
>> e.g. RTEMS-pc386
>> or RTEMS-xilinx_zynq_a9_qemu
>>
>> in epics-base/configure/os there must be a file for the target used,
>> e.g.
>> CONFIG.Common.RTEMS-xilinx_zynq_a9_qemu
>> or
>> CONFIG.Common.RTEMS-pc386
>
> Checked.  CONFIG.Common.RTEMS-pc386 was there
>>
>>
>> Then you have to set in configure/os/CONFIG_SITE.Common.RTEMS
>> where to find RTEMS:
>>
>> # Where to find RTEMS
>> #
>> # APS:
>> #RTEMS_VERSION = 4.10.2
>> #RTEMS_BASE = /usr/local/vw/rtems/rtems-$(RTEMS_VERSION)
>
>
> In my system, I entered this:
> #APS
> RTEMS_VERSION = 4.10
> RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)
>
> I followed the above instructions and used the 'make' command.
>
>
> While the earlier errors are resolved, The latest error that I have 
> encountered is this after using make command.:
>
> "...Info':
> /home/mritunjay/development/EPICS/epics-base/modules/libcom/src/O.RTEMS-pc386/../osi/os/RTEMS/osdThread.c:747:
>  undefined reference to `pthread_getschedparam'
> collect2: ld returned 1 exit status
> ../../../../configure/RULES_BUILD:212: recipe for target 'libComTestHarness' 
> failed
> make[4]: *** [libComTestHarness] Error 1
> make[4]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/test/O.RTEMS-pc386'
> ../../../configure/RULES_ARCHS:58: recipe for target 'install.RTEMS-pc386' 
> failed
> make[3]: *** [install.RTEMS-pc386] Error 2
> make[3]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/test'
> ../../configure/RULES_DIRS:85: recipe for target 'test.install' failed
> make[2]: *** [test.install] Error 2
> make[2]: Leaving directory 
> 

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-03 Thread Gedare Bloom
On Fri, Jul 3, 2020 at 9:17 AM Mritunjay Sharma
 wrote:
>
> Hello Heinz and everyone,
>
> Thank you so much, with this email, I will try to clear all the things, and 
> what is the status for now.
>
> First. let me tell you the current status: Vijay helped me last night in an 
> offlist discussion to clear the confusions which
> I was having (I will mention them below) due to which I was able to build and 
> install RTEMS 4.10 for pc386 successfully.
> With that, all my previous errors were resolved. Below is the detail of all 
> the steps, I followed.
>
> Let me tell that my development environment was earlier set up for RTEMS5. 
> For building EPICS with RTEMS,
> I thought it will be right to first build RTEMS 4.10 for pc386.
>
> In order to do that, I made the directory
>
> i) $HOME/development/rtems_dev
> ii) I extracted rtems-4.10.2 from here 
> https://ftp.rtems.org/pub/rtems/releases/4.10/4.10.2/
> iii)I created another directory rtems_dev/src
> iv)Inside src, I cloned rsb and moved to 4.10 branch.
> v) After performing checks, I entered to rsb/rtems and used this command:
> '../source-builder/sb-set-builder 
> --prefix=/home/mritunjay/development/rtems_dev/rtems-4.10.2 4.10/rtems-i386'
> Even though the build completed successfully, this was the point where I made 
> the error. I used the RTEMS source as the prefix which
> was causing all the problems.
> vi) After the discussion with Vijay and getting cleared, I deleted everything 
> except the RTEMS RSB and restarted the process with prefix and source
> different this time and rebuilt the compiler tools using RSB.
> vii) Now the directory structure under $HOME/development/rtems_dev/ looked 
> like:
>   | rtems-4.10.2
>   | 4.10
>   | src/rsb
>   | kernel/pc386
> I also used this command: "export 
> PATH=$HOME/development/rtems_dev/4.10/bin:$PATH"
> vi) Then I went to rtems_dev/rtems-4.10.2 and used this command:
> "./bootstrap -c && 
> $HOME/development/rtems_dev/src/rsb/source-builder/sb-bootstrap"
> vi) After this I went insid directory 
> $HOME/development/rtems_dev/kernel/pc-386
> vii) Inside pc-386, I used the following command:
> ''$HOME/development/rtems_dev/rtems-4.10.2/configure --target=i386-rtems4.10 
> --disable-posix  --enable-rtemsbsp=pc386 --enable-tests=samples 
> --prefix=/home/development/rtems_dev/rtems-4.10.2 --enable-cxx"
> viii) Then I entered the make command which ran successfully and the make 
> install was also successful.
>
> So all the errors were resolved and I moved on to build EPICS now for RTEMS 
> 4.10.
> I also used this command:
> '''export 
> RTEMS_MAKEFILE_PATH=$HOME/development/rtems_dev/4.10/i386-rtems4.10/pc386''
> Location of epics-base in my system is as follows:
> "$HOME/development/EPICS/epics-base"
>
> After this, I followed the tutorial you sent to build EPICS for rterms-4.10 
> for pc-386 which is:
>>
>> Very roughly:
>> git clone —recursive epics-base
>>
>> in epics-base/configure/CONFIG_SITE
>> set
>> CROSS_COMPILER_TARGET_ARCHS=
>
>What I entered:
>CROSS_COMPILER_TARGET_ARCHS=  RTEMS-pc386
>>
>> e.g. RTEMS-pc386
>> or RTEMS-xilinx_zynq_a9_qemu
>>
>> in epics-base/configure/os there must be a file for the target used,
>> e.g.
>> CONFIG.Common.RTEMS-xilinx_zynq_a9_qemu
>> or
>> CONFIG.Common.RTEMS-pc386
>
> Checked.  CONFIG.Common.RTEMS-pc386 was there
>>
>>
>> Then you have to set in configure/os/CONFIG_SITE.Common.RTEMS
>> where to find RTEMS:
>>
>> # Where to find RTEMS
>> #
>> # APS:
>> #RTEMS_VERSION = 4.10.2
>> #RTEMS_BASE = /usr/local/vw/rtems/rtems-$(RTEMS_VERSION)
>
>
> In my system, I entered this:
> #APS
> RTEMS_VERSION = 4.10
> RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)
>
> I followed the above instructions and used the 'make' command.
>
>
> While the earlier errors are resolved, The latest error that I have 
> encountered is this after using make command.:
>
> "...Info':
> /home/mritunjay/development/EPICS/epics-base/modules/libcom/src/O.RTEMS-pc386/../osi/os/RTEMS/osdThread.c:747:
>  undefined reference to `pthread_getschedparam'
> collect2: ld returned 1 exit status
> ../../../../configure/RULES_BUILD:212: recipe for target 'libComTestHarness' 
> failed
> make[4]: *** [libComTestHarness] Error 1
> make[4]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/test/O.RTEMS-pc386'
> ../../../configure/RULES_ARCHS:58: recipe for target 'install.RTEMS-pc386' 
> failed
> make[3]: *** [install.RTEMS-pc386] Error 2
> make[3]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom/test'
> ../../configure/RULES_DIRS:85: recipe for target 'test.install' failed
> make[2]: *** [test.install] Error 2
> make[2]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/modules/libcom'
> ../configure/RULES_DIRS:85: recipe for target 'libcom.install' failed
> make[1]: *** [libcom.install] Error 2
> make[1]: Leaving directory 
> '/home/mritunjay/development/EPICS/epics-base/modules'
> 

Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-03 Thread Mritunjay Sharma
Hello Heinz and everyone,

Thank you so much, with this email, I will try to clear all the things, and
what is the status for now.

First. let me tell you the current status: Vijay helped me last night in an
offlist discussion to clear the confusions which
I was having (I will mention them below) due to which I was able to build
and install RTEMS 4.10 for pc386 successfully.
With that, all my previous errors were resolved. Below is the detail of all
the steps, I followed.

Let me tell that my development environment was earlier set up for RTEMS5.
For building EPICS with RTEMS,
I thought it will be right to first build RTEMS 4.10 for pc386.

In order to do that, I made the directory

i) $HOME/development/rtems_dev
ii) I extracted rtems-4.10.2 from here
https://ftp.rtems.org/pub/rtems/releases/4.10/4.10.2/
iii)I created another directory rtems_dev/src
iv)Inside src, I cloned rsb and moved to 4.10 branch.
v) After performing checks, I entered to rsb/rtems and used this command:
'../source-builder/sb-set-builder
--prefix=/home/mritunjay/development/rtems_dev/rtems-4.10.2 4.10/rtems-i386'
Even though the build completed successfully, this was the point where I
made the error. I used the RTEMS source as the prefix which
was causing all the problems.
vi) After the discussion with Vijay and getting cleared, I deleted
everything except the RTEMS RSB and restarted the process with prefix and
source
different this time and rebuilt the compiler tools using RSB.
vii) Now the directory structure under $HOME/development/rtems_dev/ looked
like:
  | rtems-4.10.2
  | 4.10
  | src/rsb
  | kernel/pc386
I also used this command: "export
PATH=$HOME/development/rtems_dev/4.10/bin:$PATH"
vi) Then I went to rtems_dev/rtems-4.10.2 and used this command:
"./bootstrap -c &&
$HOME/development/rtems_dev/src/rsb/source-builder/sb-bootstrap"
vi) After this I went
insid directory $HOME/development/rtems_dev/kernel/pc-386
vii) Inside pc-386, I used the following command:
''$HOME/development/rtems_dev/rtems-4.10.2/configure
--target=i386-rtems4.10 --disable-posix  --enable-rtemsbsp=pc386
--enable-tests=samples --prefix=/home/development/rtems_dev/rtems-4.10.2
--enable-cxx"
viii) Then I entered the make command which ran successfully and the make
install was also successful.

So all the errors were resolved and I moved on to build EPICS now for RTEMS
4.10.
I also used this command:
'''export
RTEMS_MAKEFILE_PATH=$HOME/development/rtems_dev/4.10/i386-rtems4.10/pc386''
Location of epics-base in my system is as follows:
"$HOME/development/EPICS/epics-base"

After this, I followed the tutorial you sent to build EPICS for rterms-4.10
for pc-386 which is:

> Very roughly:
> git clone —recursive epics-base
>
> in epics-base/configure/CONFIG_SITE
> set
> CROSS_COMPILER_TARGET_ARCHS=
>
   What I entered:
   CROSS_COMPILER_TARGET_ARCHS=  RTEMS-pc386

> e.g. RTEMS-pc386
> or RTEMS-xilinx_zynq_a9_qemu
>
> in epics-base/configure/os there must be a file for the target used,
> e.g.
> CONFIG.Common.RTEMS-xilinx_zynq_a9_qemu
> or
> CONFIG.Common.RTEMS-pc386
>
Checked.  CONFIG.Common.RTEMS-pc386 was there

>
> Then you have to set in configure/os/CONFIG_SITE.Common.RTEMS
> where to find RTEMS:
>
> # Where to find RTEMS
> #
> # APS:
> #RTEMS_VERSION = 4.10.2
> #RTEMS_BASE = /usr/local/vw/rtems/rtems-$(RTEMS_VERSION)


In my system, I entered this:
#APS
RTEMS_VERSION = 4.10
RTEMS_BASE = /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)

I followed the above instructions and used the 'make' command.


While the earlier errors are resolved, The latest error that I have
encountered is this after using make command.:

"...Info':
/home/mritunjay/development/EPICS/epics-base/modules/libcom/src/O.RTEMS-pc386/../osi/os/RTEMS/osdThread.c:747:
undefined reference to `pthread_getschedparam'
collect2: ld returned 1 exit status
../../../../configure/RULES_BUILD:212: recipe for target
'libComTestHarness' failed
make[4]: *** [libComTestHarness] Error 1
make[4]: Leaving directory
'/home/mritunjay/development/EPICS/epics-base/modules/libcom/test/O.RTEMS-pc386'
../../../configure/RULES_ARCHS:58: recipe for target 'install.RTEMS-pc386'
failed
make[3]: *** [install.RTEMS-pc386] Error 2
make[3]: Leaving directory
'/home/mritunjay/development/EPICS/epics-base/modules/libcom/test'
../../configure/RULES_DIRS:85: recipe for target 'test.install' failed
make[2]: *** [test.install] Error 2
make[2]: Leaving directory
'/home/mritunjay/development/EPICS/epics-base/modules/libcom'
../configure/RULES_DIRS:85: recipe for target 'libcom.install' failed
make[1]: *** [libcom.install] Error 2
make[1]: Leaving directory
'/home/mritunjay/development/EPICS/epics-base/modules'
configure/RULES_DIRS:85: recipe for target 'modules.install' failed
make: *** [modules.install] Error 2"

I hope this time I was explicit in writing what I did and what error I am
facing as of now. It would be kind
of you to guide where I am going wrong.

Thanks,
Mritunjay





On Fri, Jul 3, 2020 at 

Re: ARM GCC machine options for RTEMS 6

2020-07-03 Thread Joel Sherrill
On Fri, Jul 3, 2020 at 2:06 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> someone from ARM changed the machine options used to build the RTEMS
> multilibs some time ago (I think GCC 8):
>
> arm-rtems6-gcc -print-multi-lib -march=armv4t
> .;
> thumb;@mthumb
> armv5te+fp/hard;@march=armv5te+fp@mfloat-abi=hard
> thumb/armv6-m;@mthumb@march=armv6-m
> thumb/armv7-a;@mthumb@march=armv7-a
> thumb/armv7-r;@mthumb@march=armv7-r
> thumb/cortex-m3;@mthumb@mcpu=cortex-m3
> thumb/cortex-m4+nofp;@mthumb@mcpu=cortex-m4+nofp
> thumb/armv7-a+simd/hard;@mthumb@march=armv7-a+simd@mfloat-abi=hard
> thumb/armv7-r+fp/hard;@mthumb@march=armv7-r+fp@mfloat-abi=hard
> thumb/cortex-m4/hard;@mthumb@mcpu=cortex-m4@mfloat-abi=hard
> thumb/cortex-m7/hard;@mthumb@mcpu=cortex-m7@mfloat-abi=hard
> eb/thumb/armv7-r;@mbig-endian@mthumb@march=armv7-r
> eb/thumb/armv7-r+fp/hard;@mbig-endian@mthumb@march=armv7-r+fp@mfloat-abi
> =hard
>
> It seems that our current machine options still map to the right multilib:
>
> arm-rtems6-gcc -print-multi-directory -march=armv7-a -mthumb -mfpu=neon
> -mfloat-abi=hard -mtune=cortex-a9
> thumb/armv7-a+simd/hard
>
> arm-rtems6-gcc -print-multi-directory -mthumb -mcpu=cortex-m4
> -mfpu=fpv4-sp-d16 -mfloat-abi=hard
> thumb/cortex-m4/hard
>
> arm-rtems6-gcc -print-multi-directory -march=armv7-r -mthumb -mbig-endian
> eb/thumb/armv7-r
>
> arm-rtems6-gcc -print-multi-directory -march=armv7-r -mthumb
> -mbig-endian -mfpu=vfpv3-d16 -mfloat-abi=hard
> eb/thumb/armv7-r+fp/hard
>
> Should we change the options to match the ones given in the multilib
> definition or should we keep the current options? If we change the
> options, then we can no longer build with GCC 7.
>

Unless they are going to remove the old options, I would tend to want to
stick
with them.

--joel

>
> ___
> 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: Applying an operation to a set of threads in RTEMS

2020-07-03 Thread dufault
My thought is that it matches what is needed and is expected to be optimized.

> On Jul 3, 2020, at 24:37 , Utkarsh Rai  wrote:
> 
> 
> 
> On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault  wrote:
> I finally have gotten to reviewing Utkarsh's work in GSOC.  One item that I 
> don't like is that there is a linked list management of the threads that have 
> access to the stack.
> I think this access is similar to the file descriptors that are blocked in a 
> select call.  On a given architecture I don't know exactly how many file 
> descriptors I can block, I don't know exactly what the FD_SET macro does, but 
> I have access to multiple file descriptors through the FD_* macros.
> 
>  
> Hello, thank you for the feedback. If I understand your suggestion correctly, 
> we can specify a file descriptor set 'fd_set' and then register the stack 
> attributes to this set, and then check for the 'current stack' through 
> select() and FD_ISSET()?
> 
> Using FD_SET and friends for specifying thread access could be a good model 
> to specify which threads need access to which thread.
> 
> My question is,  what benefit do we get by using FD_SET and friends? 
> Ultimately we will have to iterate through the set to check for the 'current 
> stack'. 
>  
> However, it won't scale infinitely.  Linked lists won't scale infinitely in 
> real-time either.
> 
> An optimization that I had in mind was to use the LRU model. This way we can 
> mark the stack attributes of the last thread as 'not current' without 
> iterating through the list or the set.
>  
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
> 
> This email is delivered through the public internet using protocols subject 
> to interception and tampering.
> 

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

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


[PATCH v1 0/1] bsps/pc386: Fix IPI for non-consecutive Apic IDs

2020-07-03 Thread Jan Sommer
Hi,

I had some time for more hardware testing of the SMP functionality on a
PC.
It turns out I missed a few places where the APICID <-> cpuid needed to be
translated.
This only occurs if the APIC Ids of different cores are not numbered
consecutively, which qemu does.

With this patch I can now run 52 examples on an Intel Atom with 4 cores.
The patch should apply to master and the 5 branch.
Did I understand it correctly, that for integrating the patch in the
RTEMS5 release, I need to first create a ticketr?

Best regards,

Jan

Jan Sommer (1):
  bsps/pc386: Fix IPI for non-consecutive APICIDs

 bsps/i386/pc386/start/smp-imps.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

-- 
2.17.1

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


[PATCH v1 1/1] bsps/pc386: Fix IPI for non-consecutive APICIDs

2020-07-03 Thread Jan Sommer
- properly use the cpu <-> apic maps for IPIs
---
 bsps/i386/pc386/start/smp-imps.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/bsps/i386/pc386/start/smp-imps.c b/bsps/i386/pc386/start/smp-imps.c
index 0985b8f08f..763ac0afc7 100644
--- a/bsps/i386/pc386/start/smp-imps.c
+++ b/bsps/i386/pc386/start/smp-imps.c
@@ -226,9 +226,11 @@ get_checksum(unsigned start, int length)
 int
 send_ipi(unsigned int dst, unsigned int v)
 {
-  int to, send_status;
+  int to, send_status, apicid;
 
-  IMPS_LAPIC_WRITE(LAPIC_ICR+0x10, (dst << 24));
+  apicid = imps_cpu_apic_map[dst];
+
+  IMPS_LAPIC_WRITE(LAPIC_ICR+0x10, (apicid << 24));
   IMPS_LAPIC_WRITE(LAPIC_ICR, v);
 
   /* Wait for send to finish */
@@ -251,9 +253,11 @@ static int
 boot_cpu(imps_processor *proc)
 {
   int apicid = proc->apic_id, success = 1;
+  int cpuid;
   unsigned bootaddr;
   unsigned bios_reset_vector = PHYS_TO_VIRTUAL(BIOS_RESET_VECTOR);
 
+  cpuid = imps_apic_cpu_map[apicid];
   /*
* Copy boot code for secondary CPUs here.  Find it in between
* "patch_code_start" and "patch_code_end" symbols.  The other CPUs
@@ -276,7 +280,7 @@ boot_cpu(imps_processor *proc)
   /* Pass start function, stack region and gdtdescr to AP
* see startAP.S for location */
   reset[1] = (uint32_t)secondary_cpu_initialize;
-  reset[2] = (uint32_t)_Per_CPU_Get_by_index(apicid)->interrupt_stack_high;
+  reset[2] = (uint32_t)_Per_CPU_Get_by_index(cpuid)->interrupt_stack_high;
   memcpy(
(char*) [3],
,
@@ -295,13 +299,13 @@ boot_cpu(imps_processor *proc)
 
   /* assert INIT IPI */
   send_ipi(
-apicid,
+cpuid,
 LAPIC_ICR_TM_LEVEL | LAPIC_ICR_LEVELASSERT | LAPIC_ICR_DM_INIT
   );
   UDELAY(1);
 
   /* de-assert INIT IPI */
-  send_ipi(apicid, LAPIC_ICR_TM_LEVEL | LAPIC_ICR_DM_INIT);
+  send_ipi(cpuid, LAPIC_ICR_TM_LEVEL | LAPIC_ICR_DM_INIT);
 
   UDELAY(1);
 
@@ -312,7 +316,7 @@ boot_cpu(imps_processor *proc)
   if (proc->apic_ver >= APIC_VER_NEW) {
 int i;
 for (i = 1; i <= 2; i++) {
-  send_ipi(apicid, LAPIC_ICR_DM_SIPI | ((bootaddr >> 12) & 0xFF));
+  send_ipi(cpuid, LAPIC_ICR_DM_SIPI | ((bootaddr >> 12) & 0xFF));
   UDELAY(1000);
 }
   }
-- 
2.17.1

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


[PATCH 0/3] Document the new build system

2020-07-03 Thread Sebastian Huber
This patch set adds an updated documetation of the new build system.
You can have a look at the generated documents here:

https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf

https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf

Changes from the previous version:

* Doorstop was removed as the tool to manage the build specification
  items.  The how-to section was updated accordingly.  Only a text
  editor is now required to manage the items.

* The documenation of the build specification item types in the RTEMS
  Software Engineering  manual is now generated by a script from
  specification items:

  https://git.rtems.org/sebh/rtems-qual.git/tree/spec2doc.py

  https://git.rtems.org/sebh/rtems-qual.git/tree/spec/spec

Sebastian Huber (3):
  common: Enable numfig role
  eng: Add build system chapter
  user: Document new build system

 common/conf.py |   3 +
 eng/build-system.rst   | 406 +
 eng/index.rst  |   1 +
 images/eng/bld-bsp.dot |  33 +++
 images/eng/bld-bsp.pdf | Bin 0 -> 15044 bytes
 images/eng/bld-bsp.png | Bin 0 -> 32435 bytes
 images/eng/bld-bsp2.dot|  42 
 images/eng/bld-bsp2.pdf| Bin 0 -> 16314 bytes
 images/eng/bld-bsp2.png| Bin 0 -> 33936 bytes
 images/eng/bld-deps.dot|  59 ++
 images/eng/bld-deps.pdf| Bin 0 -> 18559 bytes
 images/eng/bld-deps.png| Bin 0 -> 18098 bytes
 images/eng/bld-deps2.dot   |  52 +
 images/eng/bld-deps2.pdf   | Bin 0 -> 18241 bytes
 images/eng/bld-deps2.png   | Bin 0 -> 40695 bytes
 user/bld/index.rst | 283 ++
 user/index.rst |   1 +
 user/start/bootstrap.rst   |  61 --
 user/start/bsp-build.rst   | 149 ++
 user/start/bsp-test.rst|  14 +-
 user/start/index.rst   |   1 -
 user/start/preparation.rst |  10 +-
 22 files changed, 961 insertions(+), 154 deletions(-)
 create mode 100644 eng/build-system.rst
 create mode 100644 images/eng/bld-bsp.dot
 create mode 100644 images/eng/bld-bsp.pdf
 create mode 100644 images/eng/bld-bsp.png
 create mode 100644 images/eng/bld-bsp2.dot
 create mode 100644 images/eng/bld-bsp2.pdf
 create mode 100644 images/eng/bld-bsp2.png
 create mode 100644 images/eng/bld-deps.dot
 create mode 100644 images/eng/bld-deps.pdf
 create mode 100644 images/eng/bld-deps.png
 create mode 100644 images/eng/bld-deps2.dot
 create mode 100644 images/eng/bld-deps2.pdf
 create mode 100644 images/eng/bld-deps2.png
 create mode 100644 user/bld/index.rst
 delete mode 100644 user/start/bootstrap.rst

-- 
2.26.2

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


[PATCH 3/3] user: Document new build system

2020-07-03 Thread Sebastian Huber
Update #3818.
---
 user/bld/index.rst | 283 +
 user/index.rst |   1 +
 user/start/bootstrap.rst   |  61 
 user/start/bsp-build.rst   | 149 +--
 user/start/bsp-test.rst|  14 +-
 user/start/index.rst   |   1 -
 user/start/preparation.rst |  10 +-
 7 files changed, 365 insertions(+), 154 deletions(-)
 create mode 100644 user/bld/index.rst
 delete mode 100644 user/start/bootstrap.rst

diff --git a/user/bld/index.rst b/user/bld/index.rst
new file mode 100644
index 000..1b8df1a
--- /dev/null
+++ b/user/bld/index.rst
@@ -0,0 +1,283 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2019 embedded brains GmbH
+.. Copyright (C) 2019 Sebastian Huber
+
+.. index:: build system
+
+.. _BSPBuildSystem:
+
+BSP Build System
+
+
+The purpose of the BSP build system is to produce and install artefacts from 
the
+RTEMS sources such as static libraries, start files, linker command files,
+configuration header files, header files, test programs, package description
+files, and third-party build system support files.
+
+Overview
+
+
+The BSP build system consists of three components which are all included in the
+RTEMS sources
+
+* the `waf `_ meta build system command line tool,
+
+* a `wscript `_ file used by ``waf``,
+  and
+
+* a
+  `set of build specification items 
`_
+  maintained by a text editor just like other source files.
+
+The build system is controlled by the user through
+
+* commands passed to the ``waf`` command line tool,
+
+* command line options passed to ``waf``, and
+
+* configuration files (e.g. ``config.ini``) used by ``wscript`` through ``waf``
+  invocations.
+
+Configurable things which are subject to a local installation variant such as
+paths to tools are intended to be passed as command line options to the ``waf``
+command line tool.  Which BSPs are built and how they are configured by means 
of
+options is placed in configuration files (e.g. ``config.ini``).  The
+configuration files may reside anywhere in the file system and the goal is to
+have it under version control by the user.
+
+Work Flow
+=
+
+There are five steps necessary to build and install one or more BSPs.
+
+1. Select which BSPs you want to build.  See also :ref:`BSPs` and
+   ``./waf bsp_list``.
+
+2. Write a BSP build configuration file (e.g. ``config.ini``) which determines
+   which BSPs are built and how they are configured.
+
+3. Run the ``./waf configure`` command to generate the build
+   environment.
+
+4. Build the BSP artefacts with ``./waf``.  The build uses the build 
environment
+   created by ``./waf configure``.  The BSP build configuration file (e.g.
+   ``config.ini``) is no longer used and may be deleted.
+
+5. Install the BSP artefacts with ``./waf install``.
+
+Commands
+
+
+The BSP build system is controlled by invocations of the ``./waf`` command line
+tool instead of the well known ``make``.  Since waf is written in Python, a
+standard Python 2.7 or 3 installation without third-party packages is required
+to run it.  The ``./waf`` command line tool must be invoked in the RTEMS source
+tree top-level directory.
+
+Some commands accept the ``--rtems-specs`` command line option.  This option
+specifies paths to build specification items.  It is an advanced option and
+there is normally no need to use it.  It may be used to customize the build at
+the level of the build specification.  For more information see the
+`Build System` chapter of the
+`RTEMS Software Engineering 
`_
+guide.
+
+Help
+
+
+Use ``./waf --help`` to get a list of commands and options.
+
+BSP List
+
+
+The BSP list command ``./waf bsp_list`` loads the build specification items and
+generates a list of base BSPs from it.  The list is sorted by architecture and
+base BSP name.  Which base BSPs are listed can be controlled by the
+``--rtems-bsps`` command line option.  It expects a comma-separated list of
+`Python regular expressions 
`_
+which select the desired BSP variants.  The path to the build specification
+items can be specified by the ``--rtems-specs`` command line option.
+
+.. code-block:: none
+
+$ ./waf bsp_list --rtems-bsps=sparc/
+sparc/at697f
+sparc/erc32
+sparc/gr712rc
+sparc/gr740
+sparc/leon2
+sparc/leon3
+sparc/ut699
+sparc/ut700
+
+.. code-block:: none
+
+$ ./waf bsp_list --rtems-bsps='/leon,/rv64imac$'
+riscv/rv64imac
+sparc/leon2
+sparc/leon3
+
+BSP Defaults
+
+
+The BSP defaults command ``./waf bsp_defaults`` loads the build specification
+items and generates a list options with default values for each base BSP from
+it.  The list is sorted by architecture and base BSP 

[PATCH 1/3] common: Enable numfig role

2020-07-03 Thread Sebastian Huber
---
 common/conf.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/common/conf.py b/common/conf.py
index 257bc4e..8fb06db 100644
--- a/common/conf.py
+++ b/common/conf.py
@@ -75,6 +75,9 @@ exclude_patterns = []
 # The name of the Pygments (syntax highlighting) style to use.
 pygments_style = 'sphinx'
 
+# http://www.sphinx-doc.org/en/master/usage/configuration.html#confval-numfig
+numfig = True
+
 # A list of ignored prefixes for module index sorting.
 #modindex_common_prefix = []
 
-- 
2.26.2

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


ARM GCC machine options for RTEMS 6

2020-07-03 Thread Sebastian Huber

Hello,

someone from ARM changed the machine options used to build the RTEMS 
multilibs some time ago (I think GCC 8):


arm-rtems6-gcc -print-multi-lib -march=armv4t
.;
thumb;@mthumb
armv5te+fp/hard;@march=armv5te+fp@mfloat-abi=hard
thumb/armv6-m;@mthumb@march=armv6-m
thumb/armv7-a;@mthumb@march=armv7-a
thumb/armv7-r;@mthumb@march=armv7-r
thumb/cortex-m3;@mthumb@mcpu=cortex-m3
thumb/cortex-m4+nofp;@mthumb@mcpu=cortex-m4+nofp
thumb/armv7-a+simd/hard;@mthumb@march=armv7-a+simd@mfloat-abi=hard
thumb/armv7-r+fp/hard;@mthumb@march=armv7-r+fp@mfloat-abi=hard
thumb/cortex-m4/hard;@mthumb@mcpu=cortex-m4@mfloat-abi=hard
thumb/cortex-m7/hard;@mthumb@mcpu=cortex-m7@mfloat-abi=hard
eb/thumb/armv7-r;@mbig-endian@mthumb@march=armv7-r
eb/thumb/armv7-r+fp/hard;@mbig-endian@mthumb@march=armv7-r+fp@mfloat-abi=hard

It seems that our current machine options still map to the right multilib:

arm-rtems6-gcc -print-multi-directory -march=armv7-a -mthumb -mfpu=neon 
-mfloat-abi=hard -mtune=cortex-a9

thumb/armv7-a+simd/hard

arm-rtems6-gcc -print-multi-directory -mthumb -mcpu=cortex-m4 
-mfpu=fpv4-sp-d16 -mfloat-abi=hard

thumb/cortex-m4/hard

arm-rtems6-gcc -print-multi-directory -march=armv7-r -mthumb -mbig-endian
eb/thumb/armv7-r

arm-rtems6-gcc -print-multi-directory -march=armv7-r -mthumb 
-mbig-endian -mfpu=vfpv3-d16 -mfloat-abi=hard

eb/thumb/armv7-r+fp/hard

Should we change the options to match the ones given in the multilib 
definition or should we keep the current options? If we change the 
options, then we can no longer build with GCC 7.


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