Re: [PATCH rtems-net-legacy 1/2] Remove RTEMS_NETWORKING checks

[Vijay Kumar Banerjee]

On Tue, Mar 30, 2021 at 10:48 AM Gedare Bloom  wrote:
>
> On Tue, Mar 30, 2021 at 10:40 AM Vijay Kumar Banerjee  wrote:
> >
> > Hi,
> >
> >
> > On Tue, Mar 30, 2021 at 7:53 AM Gedare Bloom  wrote:
> > >
> > > On Mon, Mar 29, 2021 at 7:42 PM Vijay Kumar Banerjee  
> > > wrote:
> > > >
> > > > ping :)
> > > >
> > > > On Tue, Mar 23, 2021 at 2:10 PM Vijay Kumar Banerjee  
> > > > wrote:
> > > > >
> > > > > * Remove nfsclient wscript and build from netlegacy.py
> > > > > ---
> > > > >  bsps/powerpc/mpc55xxevb/net/smsc9218i.c |  4 +--
> > > > >  libmisc/dummy-networking.c  | 44 
> > > > > -
> > > > >  netlegacy.py| 17 +-
> > > > >  nfsclient/wscript   |  1 +
> > > > >  telnetd/telnetd.c   |  4 ---
> > > > >  wscript |  2 +-
> > > > >  6 files changed, 41 insertions(+), 31 deletions(-)
> > > > >
> > > > > diff --git a/bsps/powerpc/mpc55xxevb/net/smsc9218i.c 
> > > > > b/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
> > > > > index d88aa8a..384f9cd 100644
> > > > > --- a/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
> > > > > +++ b/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
> > > > > @@ -24,7 +24,7 @@
> > > > >
> > > > >  #include 
> > > > >
> > > > > -#if defined(RTEMS_NETWORKING) && defined(MPC55XX_HAS_SIU)
> > > > > +#if defined(MPC55XX_HAS_SIU)
> > > > >
> > > > >  #include 
> > > > >
> > > > > @@ -2121,4 +2121,4 @@ int smsc9218i_attach_detach(
> > > > >return 0;
> > > > >  }
> > > > >
> > > > > -#endif /* defined(RTEMS_NETWORKING) && defined(MPC55XX_HAS_SIU) */
> > > > > +#endif /* defined(MPC55XX_HAS_SIU) */
> > > > > diff --git a/libmisc/dummy-networking.c b/libmisc/dummy-networking.c
> > > > > index 379e23e..b7f15c8 100644
> > > > > --- a/libmisc/dummy-networking.c
> > > > > +++ b/libmisc/dummy-networking.c
> > > > > @@ -16,27 +16,25 @@
> > > > >  #include 
> > > > >
> > > > >  /* Loopback Network Configuration */
> > > > > -#if defined(RTEMS_NETWORKING)
> > > > > -  #include 
> > > > > -  #include 
> > > > > -  #include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > >
> > > > > -  struct rtems_bsdnet_config rtems_bsdnet_config = {
> > > > > -  NULL,   /* Network interface */
> > > > > -  NULL,   /* Use fixed network configuration */
> > > > > -  0,  /* Default network task priority */
> > > > > -  0,  /* Default mbuf capacity */
> > > > > -  0,  /* Default mbuf cluster capacity */
> > > > > -  "testSystem",   /* Host name */
> > > > > -  "nowhere.com",  /* Domain name */
> > > > > -  "127.0.0.1",/* Gateway */
> > > > > -  "127.0.0.1",/* Log host */
> > > > > -  {"127.0.0.1" }, /* Name server(s) */
> > > > > -  {"127.0.0.1" }, /* NTP server(s) */
> > > > > -  1,  /* sb_efficiency */
> > > > > -  0,  /* udp_tx_buf_size */
> > > > > -  0,  /* udp_rx_buf_size */
> > > > > -  0,  /* tcp_tx_buf_size */
> > > > > -  0   /* tcp_rx_buf_size */
> > > > > -  };
> > > > > -#endif
> > > > > +struct rtems_bsdnet_config rtems_bsdnet_config = {
> > > > > +NULL,   /* Network interface */
> > > > > +NULL,   /* Use fixed network configuration */
> > > > > +0,  /* Default network task priority */
> > > > > +0,  /* Default mbuf capacity */
> > > > > +0,  /* Default mbuf cluster capacity */
> > > > > +"testSystem",   /* Host name */
> > > > > +"nowhere.com",  /* Domain name */
> > > > > +"127.0.0.1",/* Gateway */
> > > > > +"127.0.0.1",/* Log host */
> > > > > +{"127.0.0.1" }, /* Name server(s) */
> > > > > +{"127.0.0.1" }, /* NTP server(s) */
> > > > > +1,  /* sb_efficiency */
> > > > > +0,  /* udp_tx_buf_size */
> > > > > +0,  /* udp_rx_buf_size */
> > > > > +0,  /* tcp_tx_buf_size */
> > > > > +0   /* tcp_rx_buf_size */
> > > > > +};
> > > > > diff --git a/netlegacy.py b/netlegacy.py
> > > > > index 0889548..0e69076 100644
> > > > > --- a/netlegacy.py
> > > > > +++ b/netlegacy.py
> > > > > @@ -54,6 +54,12 @@ def build(bld):
> > > > > for s in os.listdir('./pppd') if s[-2:] == '.c']
> > > > >  telnetd_source = [os.path.join('./telnetd', s)
> > > > >for s in os.listdir('telnetd') if s[-2:] == 
> > > > > '.c']
> > > > > +nfs_source = []
> > > > > +for root, dirs, files in os.walk('./nfsclient'):
> > > > > +for name in files:
> > > > > +if name[-2:] == '.c':
> > > can you use 

Re: #3860 - GSoC enquiries

[Gedare Bloom]

On Fri, Apr 2, 2021 at 6:09 PM Joel Sherrill  wrote:
>
>
>
> On Fri, Apr 2, 2021, 6:59 PM Gedare Bloom  wrote:
>>
>> On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine  wrote:
>> >
>> > Hello,
>> > Please can you help explain what you mean by Adding a "check-style" target 
>> > to the RTEMS build system?
>> > And how I could possibly go about this?
>> >
>> I don't know if this makes sense exactly to me.  When compiling RTEMS
>> it could be nice to have an option to check the style rules for
>> compliance. This would be something to integrate in the
>> rtems.git/wscript file most likely, as part of the waf build system.
>> However, since checking style does not generate a target file, I don't
>> know that this really is suitable as a way to verify style rules. It
>> may be suitable to add a standalone script in rtems-tools.git that can
>> be run over the rtems.git that creates a report about style problems.
>> Maybe, a way to configure it to ignore some files or to add exceptions
>> to the style rules for certain cases then could be possible.
>
>
> If you have a configuration that produces the code formatted as expected in 
> certain directories, then if a change is made as part of normal development, 
> running uncrustify will result in changes to the file needed. In a way the 
> goal is to have a directory full of files that an RTEMS uncrustify 
> configuration does not change.
>
> If you have a script that can do that manually then we can easily add an 
> automated check somewhere in the process to ensure that directories that 
> adhere to the style rules continue to adhere to them.
>
> One thing to keep in mind is that there there are places where uncrustify 
> does not have the ability to format code the way RTEMS has historically done 
> it. we want the rules to be as close as possible to the existing practice but 
> we are willing to adjust practice if it allows the tool to produce formatted 
> output we can trust.
>
Also on the table could be modifications to uncrustify.

> On each point where this type of issue occurs, we'll have to have a 
> discussion about our Style versus what tool supports. It's likely indicates 
> we're doing something that's not common in the open source world.
>
> Once the delta between the output of uncrustify and the committed source is 
> zero, running uncrustify should produce no changes. Anything uncrustify wants 
> to change at that point would be a style violation and flagged. In a perfect 
> world it would prevent you from committing.
>
>>
>>
>> I think focus on 1 and 3 is better as a way to start, and perhaps
>> something like the above can be the phase 2 effort.
>>
>> Gedare
>>
>> > Cheers,
>> > Ida
>> >
>> > On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom  wrote:
>> >>
>> >> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine  wrote:
>> >> >
>> >> > Yes I have. But wondering how to run it with the given configuration I 
>> >> > saw in this 
>> >> > thread(https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
>> >> >
>> >>
>> >> If you download/copy the configuration into a cfg file, then you can
>> >> use the examples from
>> >> https://github.com/uncrustify/uncrustify#running-the-program and
>> >> attempt to run it on some files within rtems.git/cpukit/score/src
>> >> would be my suggestion.
>> >>
>> >> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom  wrote:
>> >> >>
>> >> >> Hi Ida,
>> >> >>
>> >> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine  wrote:
>> >> >> >
>> >> >> > Hello,
>> >> >> > Please do you mind telling me how to run uncrustify with the given 
>> >> >> > configuration with any sample file?
>> >> >>
>> >> >> What have you tried? Any directions followed/attempted or notes that
>> >> >> you have taken would be helpful.
>> >> >>
>> >> >> I guess all the info that you should need is in Uncrustify's readme
>> >> >> file. https://github.com/uncrustify/uncrustify
>> >> >>
>> >> >> Did you successfully compile uncrustify tool?
>> >> >>
>> >> >> > I'm a bit stuck.
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Ida.
>> >> >> >
>> >> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom  
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine  
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> > Hello,
>> >> >> >> > So I have gone through this configuration file and I think I'm 
>> >> >> >> > getting it. However I'm a bit lost in the reading the messages in 
>> >> >> >> > the thread. Do you mind explaining? Or we can start talking about 
>> >> >> >> > a way forward.
>> >> >> >> > Also can you help me with some steps on how to test this by 
>> >> >> >> > myself if possible?
>> >> >> >> >
>> >> >> >>
>> >> >> >> It may be easier if you go "up" a level to see the full thread
>> >> >> >> context: 
>> >> >> >> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
>> >> >> >> Then you can go through the messages non-linearly. Right now, the
>> >> >> >> basic idea is to follow the steps outlined in the open project 
>> >> >> >> 

[PATCH rtems-net-legacy] netlegacy: Use os.path to get the file extension

[Vijay Kumar Banerjee]

---
 bsp_drivers.py | 5 +++--
 netlegacy.py   | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/bsp_drivers.py b/bsp_drivers.py
index cb6caa5..3ca10c6 100644
--- a/bsp_drivers.py
+++ b/bsp_drivers.py
@@ -62,9 +62,10 @@ def bsp_files(bld):
 source_dir = os.walk(special_case_dirs[bsp])
 for root, dirs, files in source_dir:
 for name in files:
-if name[-2:] == '.c':
+ext = os.path.splitext(name)[1]
+if ext == '.c':
 source_files[bsp].append(os.path.join(root, name))
-if name[-2:] == '.h':
+if ext == '.h':
 if root not in include_dirs[bsp]:
 include_dirs[bsp].append(root)
 if bsp in special_case_sources:
diff --git a/netlegacy.py b/netlegacy.py
index 85c523e..f470da2 100644
--- a/netlegacy.py
+++ b/netlegacy.py
@@ -40,9 +40,10 @@ for root, dirs, files in os.walk("."):
 dirs.append('./bsps/shared/net')
 include_files[root[2:]] = []
 for name in files:
-if name[-2:] == '.c':
+ext = os.path.splitext(name)[1]
+if ext == '.c':
 source_files.append(os.path.join(root, name))
-if name[-2:] == '.h' and name not in exclude_headers:
+if ext == '.h' and name not in exclude_headers:
 include_files[root[2:]].append(os.path.join(root, name))
 
 
-- 
2.26.2

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

[PATCH rtems-net-legacy v2] Remove RTEMS_NETWORKING checks

[Vijay Kumar Banerjee]

* Remove nfsclient wscript and build from netlegacy.py
---
 bsps/powerpc/mpc55xxevb/net/smsc9218i.c |  4 +--
 libmisc/dummy-networking.c  | 44 -
 netlegacy.py| 18 +-
 nfsclient/wscript   |  1 +
 telnetd/telnetd.c   |  4 ---
 wscript |  2 +-
 6 files changed, 42 insertions(+), 31 deletions(-)

diff --git a/bsps/powerpc/mpc55xxevb/net/smsc9218i.c 
b/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
index d88aa8a..384f9cd 100644
--- a/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
+++ b/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
@@ -24,7 +24,7 @@
 
 #include 
 
-#if defined(RTEMS_NETWORKING) && defined(MPC55XX_HAS_SIU)
+#if defined(MPC55XX_HAS_SIU)
 
 #include 
 
@@ -2121,4 +2121,4 @@ int smsc9218i_attach_detach(
   return 0;
 }
 
-#endif /* defined(RTEMS_NETWORKING) && defined(MPC55XX_HAS_SIU) */
+#endif /* defined(MPC55XX_HAS_SIU) */
diff --git a/libmisc/dummy-networking.c b/libmisc/dummy-networking.c
index 379e23e..b7f15c8 100644
--- a/libmisc/dummy-networking.c
+++ b/libmisc/dummy-networking.c
@@ -16,27 +16,25 @@
 #include 
 
 /* Loopback Network Configuration */
-#if defined(RTEMS_NETWORKING)
-  #include 
-  #include 
-  #include 
+#include 
+#include 
+#include 
 
-  struct rtems_bsdnet_config rtems_bsdnet_config = {
-  NULL,   /* Network interface */
-  NULL,   /* Use fixed network configuration */
-  0,  /* Default network task priority */
-  0,  /* Default mbuf capacity */
-  0,  /* Default mbuf cluster capacity */
-  "testSystem",   /* Host name */
-  "nowhere.com",  /* Domain name */
-  "127.0.0.1",/* Gateway */
-  "127.0.0.1",/* Log host */
-  {"127.0.0.1" }, /* Name server(s) */
-  {"127.0.0.1" }, /* NTP server(s) */
-  1,  /* sb_efficiency */
-  0,  /* udp_tx_buf_size */
-  0,  /* udp_rx_buf_size */
-  0,  /* tcp_tx_buf_size */
-  0   /* tcp_rx_buf_size */
-  };
-#endif
+struct rtems_bsdnet_config rtems_bsdnet_config = {
+NULL,   /* Network interface */
+NULL,   /* Use fixed network configuration */
+0,  /* Default network task priority */
+0,  /* Default mbuf capacity */
+0,  /* Default mbuf cluster capacity */
+"testSystem",   /* Host name */
+"nowhere.com",  /* Domain name */
+"127.0.0.1",/* Gateway */
+"127.0.0.1",/* Log host */
+{"127.0.0.1" }, /* Name server(s) */
+{"127.0.0.1" }, /* NTP server(s) */
+1,  /* sb_efficiency */
+0,  /* udp_tx_buf_size */
+0,  /* udp_rx_buf_size */
+0,  /* tcp_tx_buf_size */
+0   /* tcp_rx_buf_size */
+};
diff --git a/netlegacy.py b/netlegacy.py
index 0889548..85c523e 100644
--- a/netlegacy.py
+++ b/netlegacy.py
@@ -54,6 +54,13 @@ def build(bld):
for s in os.listdir('./pppd') if s[-2:] == '.c']
 telnetd_source = [os.path.join('./telnetd', s)
   for s in os.listdir('telnetd') if s[-2:] == '.c']
+nfs_source = []
+for root, dirs, files in os.walk('./nfsclient'):
+for name in files:
+ext = os.path.splitext(name)[1]
+if ext == '.c':
+src_root = os.path.split(root)[1]
+nfs_source.append(os.path.join('./nfsclient', src_root, name))
 
 bsp_dirs, bsp_sources = bsp_drivers.bsp_files(bld)
 
@@ -66,6 +73,7 @@ def build(bld):
  './bsps/include'])
 arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
 bld.env.RTEMS_ARCH_BSP)
+lib_path = os.path.join(bld.env.PREFIX, arch_lib_path)
 include_path.append(os.path.relpath(os.path.join(bld.env.PREFIX,
  arch_lib_path)))
 include_path.append(os.path.relpath(os.path.join(bld.env.PREFIX,
@@ -73,6 +81,8 @@ def build(bld):
  'include')))
 include_path.append('./bsps/include/libchip')
 
+bld.read_stlib('rtemsbsp', paths=[lib_path])
+
 if bsp in bsp_dirs:
 include_path.extend(bsp_dirs[bsp])
 
@@ -107,8 +117,14 @@ def build(bld):
   use='networking',
   source=telnetd_source)
 
+bld.stlib(target='nfs',
+  features='c',
+  includes=ip,
+  use=['rtemsbsp', 'networking'],
+  source=nfs_source)
+
 bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
-  ["libnetworking.a", 

Re: #3860 - GSoC enquiries

[Joel Sherrill]

On Fri, Apr 2, 2021, 6:59 PM Gedare Bloom  wrote:

> On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine  wrote:
> >
> > Hello,
> > Please can you help explain what you mean by Adding a "check-style"
> target to the RTEMS build system?
> > And how I could possibly go about this?
> >
> I don't know if this makes sense exactly to me.  When compiling RTEMS
> it could be nice to have an option to check the style rules for
> compliance. This would be something to integrate in the
> rtems.git/wscript file most likely, as part of the waf build system.
> However, since checking style does not generate a target file, I don't
> know that this really is suitable as a way to verify style rules. It
> may be suitable to add a standalone script in rtems-tools.git that can
> be run over the rtems.git that creates a report about style problems.
> Maybe, a way to configure it to ignore some files or to add exceptions
> to the style rules for certain cases then could be possible.
>

If you have a configuration that produces the code formatted as expected in
certain directories, then if a change is made as part of normal
development, running uncrustify will result in changes to the file needed.
In a way the goal is to have a directory full of files that an RTEMS
uncrustify configuration does not change.

If you have a script that can do that manually then we can easily add an
automated check somewhere in the process to ensure that directories that
adhere to the style rules continue to adhere to them.

One thing to keep in mind is that there there are places where uncrustify
does not have the ability to format code the way RTEMS has historically
done it. we want the rules to be as close as possible to the existing
practice but we are willing to adjust practice if it allows the tool to
produce formatted output we can trust.

On each point where this type of issue occurs, we'll have to have a
discussion about our Style versus what tool supports. It's likely indicates
we're doing something that's not common in the open source world.

Once the delta between the output of uncrustify and the committed source is
zero, running uncrustify should produce no changes. Anything uncrustify
wants to change at that point would be a style violation and flagged. In a
perfect world it would prevent you from committing.


>
> I think focus on 1 and 3 is better as a way to start, and perhaps
> something like the above can be the phase 2 effort.
>
> Gedare
>
> > Cheers,
> > Ida
> >
> > On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom  wrote:
> >>
> >> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine  wrote:
> >> >
> >> > Yes I have. But wondering how to run it with the given configuration
> I saw in this thread(
> https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
> >> >
> >>
> >> If you download/copy the configuration into a cfg file, then you can
> >> use the examples from
> >> https://github.com/uncrustify/uncrustify#running-the-program and
> >> attempt to run it on some files within rtems.git/cpukit/score/src
> >> would be my suggestion.
> >>
> >> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom 
> wrote:
> >> >>
> >> >> Hi Ida,
> >> >>
> >> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine 
> wrote:
> >> >> >
> >> >> > Hello,
> >> >> > Please do you mind telling me how to run uncrustify with the given
> configuration with any sample file?
> >> >>
> >> >> What have you tried? Any directions followed/attempted or notes that
> >> >> you have taken would be helpful.
> >> >>
> >> >> I guess all the info that you should need is in Uncrustify's readme
> >> >> file. https://github.com/uncrustify/uncrustify
> >> >>
> >> >> Did you successfully compile uncrustify tool?
> >> >>
> >> >> > I'm a bit stuck.
> >> >> >
> >> >> > Thanks,
> >> >> > Ida.
> >> >> >
> >> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom 
> wrote:
> >> >> >>
> >> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine 
> wrote:
> >> >> >> >
> >> >> >> > Hello,
> >> >> >> > So I have gone through this configuration file and I think I'm
> getting it. However I'm a bit lost in the reading the messages in the
> thread. Do you mind explaining? Or we can start talking about a way forward.
> >> >> >> > Also can you help me with some steps on how to test this by
> myself if possible?
> >> >> >> >
> >> >> >>
> >> >> >> It may be easier if you go "up" a level to see the full thread
> >> >> >> context:
> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
> >> >> >> Then you can go through the messages non-linearly. Right now, the
> >> >> >> basic idea is to follow the steps outlined in the open project
> ticket.
> >> >> >> I think Christian has summarized it nicely in his recent email
> [1]: "I
> >> >> >> think the contributions from this project that would add value
> would
> >> >> >> be:
> >> >> >> 1. Finding a tool and a configuration that can do an RTEMS style
> or an
> >> >> >> acceptable close one.
> >> >> >> 2. Adding a "check-style" target to our build system.
> >> >> >> 

Re: #3860 - GSoC enquiries

[Gedare Bloom]

On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine  wrote:
>
> Hello,
> Please can you help explain what you mean by Adding a "check-style" target to 
> the RTEMS build system?
> And how I could possibly go about this?
>
I don't know if this makes sense exactly to me.  When compiling RTEMS
it could be nice to have an option to check the style rules for
compliance. This would be something to integrate in the
rtems.git/wscript file most likely, as part of the waf build system.
However, since checking style does not generate a target file, I don't
know that this really is suitable as a way to verify style rules. It
may be suitable to add a standalone script in rtems-tools.git that can
be run over the rtems.git that creates a report about style problems.
Maybe, a way to configure it to ignore some files or to add exceptions
to the style rules for certain cases then could be possible.

I think focus on 1 and 3 is better as a way to start, and perhaps
something like the above can be the phase 2 effort.

Gedare

> Cheers,
> Ida
>
> On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom  wrote:
>>
>> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine  wrote:
>> >
>> > Yes I have. But wondering how to run it with the given configuration I saw 
>> > in this 
>> > thread(https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
>> >
>>
>> If you download/copy the configuration into a cfg file, then you can
>> use the examples from
>> https://github.com/uncrustify/uncrustify#running-the-program and
>> attempt to run it on some files within rtems.git/cpukit/score/src
>> would be my suggestion.
>>
>> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom  wrote:
>> >>
>> >> Hi Ida,
>> >>
>> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine  wrote:
>> >> >
>> >> > Hello,
>> >> > Please do you mind telling me how to run uncrustify with the given 
>> >> > configuration with any sample file?
>> >>
>> >> What have you tried? Any directions followed/attempted or notes that
>> >> you have taken would be helpful.
>> >>
>> >> I guess all the info that you should need is in Uncrustify's readme
>> >> file. https://github.com/uncrustify/uncrustify
>> >>
>> >> Did you successfully compile uncrustify tool?
>> >>
>> >> > I'm a bit stuck.
>> >> >
>> >> > Thanks,
>> >> > Ida.
>> >> >
>> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom  wrote:
>> >> >>
>> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine  wrote:
>> >> >> >
>> >> >> > Hello,
>> >> >> > So I have gone through this configuration file and I think I'm 
>> >> >> > getting it. However I'm a bit lost in the reading the messages in 
>> >> >> > the thread. Do you mind explaining? Or we can start talking about a 
>> >> >> > way forward.
>> >> >> > Also can you help me with some steps on how to test this by myself 
>> >> >> > if possible?
>> >> >> >
>> >> >>
>> >> >> It may be easier if you go "up" a level to see the full thread
>> >> >> context: 
>> >> >> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
>> >> >> Then you can go through the messages non-linearly. Right now, the
>> >> >> basic idea is to follow the steps outlined in the open project ticket.
>> >> >> I think Christian has summarized it nicely in his recent email [1]: "I
>> >> >> think the contributions from this project that would add value would
>> >> >> be:
>> >> >> 1. Finding a tool and a configuration that can do an RTEMS style or an
>> >> >> acceptable close one.
>> >> >> 2. Adding a "check-style" target to our build system.
>> >> >> 3. Maybe add some kind of script similar to Linux "checkpatch.pl" that
>> >> >> could check whether patches would need changes _before_ they are
>> >> >> applied.
>> >> >> "
>> >> >>
>> >> >> The proposal preparation phase should work through identifying the
>> >> >> options and pros/cons for different tools while preparing a plan for
>> >> >> how to integrate style checks in 2, 3 and thinking through the coding
>> >> >> tasks for the summer.
>> >> >>
>> >> >> Getting the style checking tool's configuration to match with the
>> >> >> RTEMS style will be some effort, and testing it out and submitting
>> >> >> some patches based on it could be a good proposal activity also to
>> >> >> build some confidence about the tools that will be used.
>> >> >>
>> >> >> We also have some Python style guidelines that might be worth
>> >> >> addressing. Those are harder maybe, since the style refactoring might
>> >> >> be challenging to review for correctness.
>> >> >>
>> >> >> For getting started, I would recommend that you try running uncrustify
>> >> >> with the given configuration on some files in RTEMS, see what it
>> >> >> results in. Play around.
>> >> >>
>> >> >> [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html
>> >> >>
>> >> >> -Gedare
>> >> >>
>> >> >> > Thanks,
>> >> >> > Ida
>> >> >> >
>> >> >> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom  
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> See the related thread, and we'll have to discuss how to move 
>> >> >> >> forward.

Re: #3860 - GSoC enquiries

[Ida Delphine]

Hello,
Please can you help explain what you mean by *Adding a "check-style" target
to the RTEMS build system*?
And how I could possibly go about this?

Cheers,
Ida

On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom  wrote:

> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine  wrote:
> >
> > Yes I have. But wondering how to run it with the given configuration I
> saw in this thread(
> https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
> >
>
> If you download/copy the configuration into a cfg file, then you can
> use the examples from
> https://github.com/uncrustify/uncrustify#running-the-program and
> attempt to run it on some files within rtems.git/cpukit/score/src
> would be my suggestion.
>
> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom  wrote:
> >>
> >> Hi Ida,
> >>
> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine  wrote:
> >> >
> >> > Hello,
> >> > Please do you mind telling me how to run uncrustify with the given
> configuration with any sample file?
> >>
> >> What have you tried? Any directions followed/attempted or notes that
> >> you have taken would be helpful.
> >>
> >> I guess all the info that you should need is in Uncrustify's readme
> >> file. https://github.com/uncrustify/uncrustify
> >>
> >> Did you successfully compile uncrustify tool?
> >>
> >> > I'm a bit stuck.
> >> >
> >> > Thanks,
> >> > Ida.
> >> >
> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom 
> wrote:
> >> >>
> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine 
> wrote:
> >> >> >
> >> >> > Hello,
> >> >> > So I have gone through this configuration file and I think I'm
> getting it. However I'm a bit lost in the reading the messages in the
> thread. Do you mind explaining? Or we can start talking about a way forward.
> >> >> > Also can you help me with some steps on how to test this by myself
> if possible?
> >> >> >
> >> >>
> >> >> It may be easier if you go "up" a level to see the full thread
> >> >> context:
> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769
> >> >> Then you can go through the messages non-linearly. Right now, the
> >> >> basic idea is to follow the steps outlined in the open project
> ticket.
> >> >> I think Christian has summarized it nicely in his recent email [1]:
> "I
> >> >> think the contributions from this project that would add value would
> >> >> be:
> >> >> 1. Finding a tool and a configuration that can do an RTEMS style or
> an
> >> >> acceptable close one.
> >> >> 2. Adding a "check-style" target to our build system.
> >> >> 3. Maybe add some kind of script similar to Linux "checkpatch.pl"
> that
> >> >> could check whether patches would need changes _before_ they are
> >> >> applied.
> >> >> "
> >> >>
> >> >> The proposal preparation phase should work through identifying the
> >> >> options and pros/cons for different tools while preparing a plan for
> >> >> how to integrate style checks in 2, 3 and thinking through the coding
> >> >> tasks for the summer.
> >> >>
> >> >> Getting the style checking tool's configuration to match with the
> >> >> RTEMS style will be some effort, and testing it out and submitting
> >> >> some patches based on it could be a good proposal activity also to
> >> >> build some confidence about the tools that will be used.
> >> >>
> >> >> We also have some Python style guidelines that might be worth
> >> >> addressing. Those are harder maybe, since the style refactoring might
> >> >> be challenging to review for correctness.
> >> >>
> >> >> For getting started, I would recommend that you try running
> uncrustify
> >> >> with the given configuration on some files in RTEMS, see what it
> >> >> results in. Play around.
> >> >>
> >> >> [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html
> >> >>
> >> >> -Gedare
> >> >>
> >> >> > Thanks,
> >> >> > Ida
> >> >> >
> >> >> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom 
> wrote:
> >> >> >>
> >> >> >> See the related thread, and we'll have to discuss how to move
> forward.
> >> >> >> The existing approach provides an uncrustify script:
> >> >> >> https://lists.rtems.org/pipermail/devel/2020-October/062769.html
> >> >> >>
> >> >> >>
> >> >> >> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine 
> wrote:
> >> >> >> >
> >> >> >> > Hello everyone,
> >> >> >> > This ticket(https://devel.rtems.org/ticket/3860) was proposed
> to me and I'm interested in it for GSoC.
> >> >> >> > The first task there is to find a code checker or formater that
> can produce results that match the RTEMS coding conventions. It also made
> mention some tools have been discussed in the past. Please I will love
> suggestions on possible tools I could use to achieve this.
> >> >> >> >
> >> >> >> >
> >> >> >> > Cheers,
> >> >> >> > Ida.
> >> >> >> > ___
> >> >> >> > devel mailing list
> >> >> >> > devel@rtems.org
> >> >> >> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org

Re: Ticket#3889 updated

[zack_on_the_speed_chanel]

Yes the build works successfully. I tried to also just try BUILD_PSXTESTS only 
and it failed midway. I also tried to do an automated build. It failed with 
__start symbol not found.


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Thursday, April 1, 2021 10:10 PM, Gedare Bloom  wrote:

> On Thu, Apr 1, 2021 at 2:52 PM zack_on_the_speed_chanel
> zack_on_the_speed_cha...@protonmail.ch wrote:
>
> > Did i do anything wrong with my .ini file?
> > Sent with ProtonMail Secure Email.
> > ‐‐‐ Original Message ‐‐‐
> > On Wednesday, March 31, 2021 12:20 AM, zack_on_the_speed_chanel 
> > zack_on_the_speed_cha...@protonmail.ch wrote:
> >
> > > my waf file look like this
> > > $cat config.ini
> > > [sparc/leon3]
> > > BUILD_TESTS=True
> > > for rebuilding the bsp I ran:
> > > ./waf configure
> > > ./waf
>
> This looks right, nothing obvious to me.
>
> Does the waf build finish successfully, or does it stop with an error?
>
> > > Zack
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐ Original Message ‐‐‐
> > > On Tuesday, March 30, 2021 9:02 PM, Gedare Bloom ged...@rtems.org wrote:
> > >
> > > > On Tue, Mar 30, 2021 at 2:41 PM zack_on_the_speed_chanel
> > > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > > >
> > > > > I have both of the options and i tried to built it with BUILD_TESTS 
> > > > > and PSXTESTS and the test didn't build. Is there anything else that 
> > > > > could alter how rtems is built?
> > > >
> > > > After you set them to True, did you re-run waf configure before waf 
> > > > build?
> > > >
> > > > > Sent with ProtonMail Secure Email.
> > > > > ‐‐‐ Original Message ‐‐‐
> > > > > On Tuesday, March 30, 2021 3:29 PM, Gedare Bloom ged...@rtems.org 
> > > > > wrote:
> > > > >
> > > > > > BUILD_TESTS and BUILD_PSXTESTS are two options that
> > > > > > if either is True it should build psxclock02.
> > > > > > On Tue, Mar 30, 2021 at 9:20 AM zack_on_the_speed_chanel
> > > > > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > > > > >
> > > > > > > I did build the leon3 bsp and I still don't see the psxtimer02 as 
> > > > > > > an executable. Is there a way build a test from source? I have 
> > > > > > > the sources for psxtest02. Also i'm thinking that it could be due 
> > > > > > > to the fact that i don't have posix tests enabled. Is there a way
> > > > > > > that to enable posix?
> > > > > > > Thanks
> > > > > > > Zack
> > > > > > > Sent with ProtonMail Secure Email.
> > > > > > > ‐‐‐ Original Message ‐‐‐
> > > > > > > On Monday, March 29, 2021 8:11 PM, zack_on_the_speed_chanel 
> > > > > > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > > > > > >
> > > > > > > > Sorry that assumption was very native of me that i didn't have 
> > > > > > > > a working baseline. Joel said that the erc32 was similar to the 
> > > > > > > > leon bsp
> > > > > > > > "
> > > > > > > > The ERC32 what's the first space hardened sparc processor. The 
> > > > > > > > leon3 is a
> > > > > > > > later processor in the same family. Both use the same build of 
> > > > > > > > GCC and are
> > > > > > > > just different bsps. In fact both run on the same sis 
> > > > > > > > simulator. "
> > > > > > > > I also though that the bsps were the same and I can work on the 
> > > > > > > > issue with only the erc32 BSP. I have one more question: when i 
> > > > > > > > run the hello world test. All the test files are within one 
> > > > > > > > specific directory and I don't see the executables for specific 
> > > > > > > > bsps that's why i thought all tests would be built (there would 
> > > > > > > > not be any specific considerations for bsps) .
> > > > > > > > Sent with ProtonMail Secure Email.
> > > > > > > > ‐‐‐ Original Message ‐‐‐
> > > > > > > > On Monday, March 29, 2021 2:45 PM, Gedare Bloom 
> > > > > > > > ged...@rtems.org wrote:
> > > > > > > >
> > > > > > > > > On Sun, Mar 28, 2021 at 1:26 PM zack_on_the_speed_chanel
> > > > > > > > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > > > > > > > >
> > > > > > > > > > Hello all,
> > > > > > > > > > I'm updating on what' i've found out with the issue (forgot 
> > > > > > > > > > to reply all) . Joel recommended me check the coverage for 
> > > > > > > > > > the leon BSP( to check if it's supported) and i found that 
> > > > > > > > > > the branch with CLOCK_MONOTONIC was not reached I think now 
> > > > > > > > > > that it's supported (because the annotated assembly is in 
> > > > > > > > > > the sparc instruction set). I also found out that the test 
> > > > > > > > > > would be similar to Psxclock02 and it runs the same tests 
> > > > > > > > > > on a different clock. Then I tried to build the psxclock02 
> > > > > > > > > > test , change the create_clock to have the clock_monotonic 
> > > > > > > > > > argument and i didn't see the executable or any change in 
> > > > > > > > > > the ./waf build. Then I was suggested that you have to 
> > > > > > > > > > enable all tests some how? How do i enable all 

Re: [PATCH rtems-docs v2 1/2] Added FAQ page

[Joel Sherrill]

On Fri, Apr 2, 2021 at 2:26 PM Gedare Bloom  wrote:

> On Fri, Apr 2, 2021 at 12:19 PM Ayushman Mishra
>  wrote:
> >
> > ---
> >  user/bld/index.rst   |   2 +
> >  user/overview/index.rst  |   2 +
> >  user/start/faq.rst   | 295 +++
> >  user/start/index.rst |   1 +
> >  user/support/contrib.rst |  96 +-
> >  user/support/support-project.rst |   2 +
> >  6 files changed, 303 insertions(+), 95 deletions(-)
> >  create mode 100644 user/start/faq.rst
> >
> > diff --git a/user/bld/index.rst b/user/bld/index.rst
> > index ebedf5a..0cccde2 100644
> > --- a/user/bld/index.rst
> > +++ b/user/bld/index.rst
> > @@ -284,6 +284,8 @@ example configuration file, building of the tests is
> enabled for the
> >
> >  [riscv/griscv]
> >
> > +.. _Migration_from_AutoconfAutomake:
> > +
> >  Migration from Autoconf/Automake
> >  
> >
> > diff --git a/user/overview/index.rst b/user/overview/index.rst
> > index 550724a..0703ede 100644
> > --- a/user/overview/index.rst
> > +++ b/user/overview/index.rst
> > @@ -20,6 +20,8 @@ You are someone looking for a real-time operating
> system.  This document
> >
> >  - helps you to build an example application on top of RTEMS.
> >
> > +.. _Features:
> > +
> >  Features
> >  
> >
> > diff --git a/user/start/faq.rst b/user/start/faq.rst
> > new file mode 100644
> > index 000..910ef8b
> > --- /dev/null
> > +++ b/user/start/faq.rst
> > @@ -0,0 +1,295 @@
> > +Frequently Asked Questions
> > +==
> > +
> > +What is RTEMS ?
> No whitespace before punctuation. "What is RTEMS?"
>
> > +---
> > +
> > +RTEMS is an open source real-time executive which provides a high
> performance
> > +environment for embedded real-time applications including many features.
> > +
> > +The RTEMS Project is the umbrella term used to describe the collection
> of
> > +individuals, companies, universities, and research institutions that
> collectively
> > +maintain and enhance the RTEMS software base.
> > +
> > +RTEMS is designed to support applications with the most stringent
> real-time
> > +requirements while being compatible with open standards such as POSIX.
> > +RTEMS includes optional functional features such as TCP/IP and various
> file
> > +systems while still offering minimum executable sizes under 20 KB in
> useful
> > +configurations.
> > +
> > +:ref:`More Features`
> > +
> > +Where can I get RTEMS ?
> > +-
> > +
> > +:ref:`Downloading RTEMS`
> > +
>
> What happened to:
> How can I pronounce RTEMS like Joel?
>

 This is clearly the most important question in the FAQ <.sarcasm>

>
>
> > +What does RTEMS stand for ?
> > +-
> > +
> > +RTEMS is an an acronym for the Real-Time Executive for Multiprocessor
> Systems.
> "an an" (typo in original wiki page :)
>
> > +
> > +Initially RTEMS stood for the Real-Time Executive for Missile Systems
> but as it
> > +became clear that the application domains that could use RTEMS extended
> far
> > +beyond missiles, the "M" changed to mean Military. When maintenance of
> RTEMS
> > +transferred to OAR, the "M" was changed again to Multiprocessor.
> > +
> > +At one point, there were both Ada and C implementations of RTEMS.
> > +Version 3.2.1 was the last RTEMS version to have implementations in both
> > +languages. Supporting the Classic API Ada implementation was painful
> and fraught
> > +with compiler specific pitfalls. With version 3.5.x, the POSIX API was
> added as
> > +the means to support the GNU Ada Translator (GNAT). This effectively
> eliminated
> > +the need for an implementation in Ada as the C implementation could
> effectively
> > +support both languages.
>

> +
> > +Are there restrictions on the RTEMS License ?
> > +
> > +
> > +RTEMS RTEMS is licensed under a combination of permissive licenses and a
> > +modified version of the GNU General Public License (GPL).
> > +For source code "Two Clause BSD” (BSD-2-Clause) and
> > +for documentation CC-BY-SA-4.0 license is preferred.
> > +The modification places no restrictions on the applications which use
> RTEMS but
> > +protects the interests of those who work on RTEMS.
> > +
> > +`License in RTEMS
> > + > +license-requirements.html>`__
> > +
>
> add the other questions even if their pages are missing, and maybe add
> a "TBD" stub or something so someone can provide the answers.
>
> Here would be "Are there Export Restrictions? on RTEMS?"
>
> > +What standards are supported by RTEMS?
> > +-
> > +
> > +The original "Classic" RTEMS API is based on the Real-Time Executive
> Interface
> > +Definition (RTEID) and the Open Real-Time Kernel Interface Definition
> (ORKID).
> > +RTEMS also 

Re: Ticket#3889 updated

[Gedare Bloom]

On Fri, Apr 2, 2021 at 12:19 PM zack_on_the_speed_chanel
 wrote:
>
> Yes the build works successfully. I tried to also just try BUILD_PSXTESTS 
> only and it failed midway. I also tried to do an automated build. It failed 
> with __start symbol not found.
>
>
You also need to enable the POSIX API/signals, in your config.ini add
RTEMS_POSIX_API = True

> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, April 1, 2021 10:10 PM, Gedare Bloom  wrote:
>
> > On Thu, Apr 1, 2021 at 2:52 PM zack_on_the_speed_chanel
> > zack_on_the_speed_cha...@protonmail.ch wrote:
> >
> > > Did i do anything wrong with my .ini file?
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐ Original Message ‐‐‐
> > > On Wednesday, March 31, 2021 12:20 AM, zack_on_the_speed_chanel 
> > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > >
> > > > my waf file look like this
> > > > $cat config.ini
> > > > [sparc/leon3]
> > > > BUILD_TESTS=True
> > > > for rebuilding the bsp I ran:
> > > > ./waf configure
> > > > ./waf
> >
> > This looks right, nothing obvious to me.
> >
> > Does the waf build finish successfully, or does it stop with an error?
> >
> > > > Zack
> > > > Sent with ProtonMail Secure Email.
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On Tuesday, March 30, 2021 9:02 PM, Gedare Bloom ged...@rtems.org wrote:
> > > >
> > > > > On Tue, Mar 30, 2021 at 2:41 PM zack_on_the_speed_chanel
> > > > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > > > >
> > > > > > I have both of the options and i tried to built it with BUILD_TESTS 
> > > > > > and PSXTESTS and the test didn't build. Is there anything else that 
> > > > > > could alter how rtems is built?
> > > > >
> > > > > After you set them to True, did you re-run waf configure before waf 
> > > > > build?
> > > > >
> > > > > > Sent with ProtonMail Secure Email.
> > > > > > ‐‐‐ Original Message ‐‐‐
> > > > > > On Tuesday, March 30, 2021 3:29 PM, Gedare Bloom ged...@rtems.org 
> > > > > > wrote:
> > > > > >
> > > > > > > BUILD_TESTS and BUILD_PSXTESTS are two options that
> > > > > > > if either is True it should build psxclock02.
> > > > > > > On Tue, Mar 30, 2021 at 9:20 AM zack_on_the_speed_chanel
> > > > > > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > > > > > >
> > > > > > > > I did build the leon3 bsp and I still don't see the psxtimer02 
> > > > > > > > as an executable. Is there a way build a test from source? I 
> > > > > > > > have the sources for psxtest02. Also i'm thinking that it could 
> > > > > > > > be due to the fact that i don't have posix tests enabled. Is 
> > > > > > > > there a way
> > > > > > > > that to enable posix?
> > > > > > > > Thanks
> > > > > > > > Zack
> > > > > > > > Sent with ProtonMail Secure Email.
> > > > > > > > ‐‐‐ Original Message ‐‐‐
> > > > > > > > On Monday, March 29, 2021 8:11 PM, zack_on_the_speed_chanel 
> > > > > > > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > > > > > > >
> > > > > > > > > Sorry that assumption was very native of me that i didn't 
> > > > > > > > > have a working baseline. Joel said that the erc32 was similar 
> > > > > > > > > to the leon bsp
> > > > > > > > > "
> > > > > > > > > The ERC32 what's the first space hardened sparc processor. 
> > > > > > > > > The leon3 is a
> > > > > > > > > later processor in the same family. Both use the same build 
> > > > > > > > > of GCC and are
> > > > > > > > > just different bsps. In fact both run on the same sis 
> > > > > > > > > simulator. "
> > > > > > > > > I also though that the bsps were the same and I can work on 
> > > > > > > > > the issue with only the erc32 BSP. I have one more question: 
> > > > > > > > > when i run the hello world test. All the test files are 
> > > > > > > > > within one specific directory and I don't see the executables 
> > > > > > > > > for specific bsps that's why i thought all tests would be 
> > > > > > > > > built (there would not be any specific considerations for 
> > > > > > > > > bsps) .
> > > > > > > > > Sent with ProtonMail Secure Email.
> > > > > > > > > ‐‐‐ Original Message ‐‐‐
> > > > > > > > > On Monday, March 29, 2021 2:45 PM, Gedare Bloom 
> > > > > > > > > ged...@rtems.org wrote:
> > > > > > > > >
> > > > > > > > > > On Sun, Mar 28, 2021 at 1:26 PM zack_on_the_speed_chanel
> > > > > > > > > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > > > > > > > > >
> > > > > > > > > > > Hello all,
> > > > > > > > > > > I'm updating on what' i've found out with the issue 
> > > > > > > > > > > (forgot to reply all) . Joel recommended me check the 
> > > > > > > > > > > coverage for the leon BSP( to check if it's supported) 
> > > > > > > > > > > and i found that the branch with CLOCK_MONOTONIC was not 
> > > > > > > > > > > reached I think now that it's supported (because the 
> > > > > > > > > > > annotated assembly is in the sparc instruction set). I 
> > > > > > > > > > > also found out that the test would be similar to 
> > > > > > > > > > > 

Re: [PATCH 1/2] Added FAQ page

[Gedare Bloom]

On Fri, Apr 2, 2021 at 12:55 PM Joel Sherrill  wrote:
>
>
>
> On Fri, Apr 2, 2021 at 1:50 PM Ayushman Mishra  
> wrote:
>>
>> Sir, It was given as an issue https://devel.rtems.org/ticket/3958 (
>> Review wiki/TBR/Website/FAQ for correct links) for the faq page
>> https://devel.rtems.org/wiki/TBR/Website/FAQ
>
>
> Thanks for confirming that. When Gedare acks the patches as being
> ok by him, I will see about removing that page and fixing links to it.
>
> --joel
>>
>>
>>
>> On Sat, Apr 3, 2021 at 12:10 AM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Fri, Apr 2, 2021 at 1:19 PM Ayushman Mishra  
>> > wrote:
>> >>
>> >> Greetings Sir,
>> >> I have corrected and send patches regarding FAQ page in user manual.I
>> >> was able to build the page on my system and also attached a
>> >> screen-shot of the builded page on browser . I have corrected
>> >> whitespace consistency and reference links according to other
>> >> doc-pages
>> >
>> >
>> > Random question. Is this information from the Wiki or just an update
>> > of what was already in rtems-docs? If this obsoletes any information
>> > in the wiki, I would like to know so we can remove it.
>> >
>> >>
>> >> . Regarding the issue of cross-link between docs , I had
>> >> sent mail on devel mail list
>> >> https://lists.rtems.org/pipermail/devel/2021-March/065882.html but
>> >> haven't got any response , so few days ago after a little discussion
>> >> on discord vijay sir said to post the patch and someone might point it
>> >> to a better way if it exists.
>> >
>> >
>> > I don't know if we know the answer to that with Sphinx. If "we" do, then
>> > I am not part of that "we".  Hopefully someone will educate us. :)
>> >
>> > Gedare.. is the new patch OK? It must be in another thread because
>> > I don't see it here.
>> >
>> > --joel
Patch needs a little bit of tweaking. It's close.

The problem with the cross-doc links is that they are wrong for a
release doc. I don't think we have determined what is the proper
solution to follow yet. They also don't populate the section numbers
in PDF builds, so all you get is the URL and if you have printed
manuals (does anyone do that?) you might not be able to find what you
want. There's no good answer to this problem though, so I'm ok with
merging the patch after the other issues get addressed, but we're
probably adding more effort to the release/post-release procedures
until someone sorts out how to do cross-doc links in a useful way.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v2 1/2] Added FAQ page

[Gedare Bloom]

On Fri, Apr 2, 2021 at 12:19 PM Ayushman Mishra
 wrote:
>
> ---
>  user/bld/index.rst   |   2 +
>  user/overview/index.rst  |   2 +
>  user/start/faq.rst   | 295 +++
>  user/start/index.rst |   1 +
>  user/support/contrib.rst |  96 +-
>  user/support/support-project.rst |   2 +
>  6 files changed, 303 insertions(+), 95 deletions(-)
>  create mode 100644 user/start/faq.rst
>
> diff --git a/user/bld/index.rst b/user/bld/index.rst
> index ebedf5a..0cccde2 100644
> --- a/user/bld/index.rst
> +++ b/user/bld/index.rst
> @@ -284,6 +284,8 @@ example configuration file, building of the tests is 
> enabled for the
>
>  [riscv/griscv]
>
> +.. _Migration_from_AutoconfAutomake:
> +
>  Migration from Autoconf/Automake
>  
>
> diff --git a/user/overview/index.rst b/user/overview/index.rst
> index 550724a..0703ede 100644
> --- a/user/overview/index.rst
> +++ b/user/overview/index.rst
> @@ -20,6 +20,8 @@ You are someone looking for a real-time operating system.  
> This document
>
>  - helps you to build an example application on top of RTEMS.
>
> +.. _Features:
> +
>  Features
>  
>
> diff --git a/user/start/faq.rst b/user/start/faq.rst
> new file mode 100644
> index 000..910ef8b
> --- /dev/null
> +++ b/user/start/faq.rst
> @@ -0,0 +1,295 @@
> +Frequently Asked Questions
> +==
> +
> +What is RTEMS ?
No whitespace before punctuation. "What is RTEMS?"

> +---
> +
> +RTEMS is an open source real-time executive which provides a high performance
> +environment for embedded real-time applications including many features.
> +
> +The RTEMS Project is the umbrella term used to describe the collection of
> +individuals, companies, universities, and research institutions that 
> collectively
> +maintain and enhance the RTEMS software base.
> +
> +RTEMS is designed to support applications with the most stringent real-time
> +requirements while being compatible with open standards such as POSIX.
> +RTEMS includes optional functional features such as TCP/IP and various file
> +systems while still offering minimum executable sizes under 20 KB in useful
> +configurations.
> +
> +:ref:`More Features`
> +
> +Where can I get RTEMS ?
> +-
> +
> +:ref:`Downloading RTEMS`
> +

What happened to:
How can I pronounce RTEMS like Joel?


> +What does RTEMS stand for ?
> +-
> +
> +RTEMS is an an acronym for the Real-Time Executive for Multiprocessor 
> Systems.
"an an" (typo in original wiki page :)

> +
> +Initially RTEMS stood for the Real-Time Executive for Missile Systems but as 
> it
> +became clear that the application domains that could use RTEMS extended far
> +beyond missiles, the "M" changed to mean Military. When maintenance of RTEMS
> +transferred to OAR, the "M" was changed again to Multiprocessor.
> +
> +At one point, there were both Ada and C implementations of RTEMS.
> +Version 3.2.1 was the last RTEMS version to have implementations in both
> +languages. Supporting the Classic API Ada implementation was painful and 
> fraught
> +with compiler specific pitfalls. With version 3.5.x, the POSIX API was added 
> as
> +the means to support the GNU Ada Translator (GNAT). This effectively 
> eliminated
> +the need for an implementation in Ada as the C implementation could 
> effectively
> +support both languages.
> +
> +Are there restrictions on the RTEMS License ?
> +
> +
> +RTEMS RTEMS is licensed under a combination of permissive licenses and a
> +modified version of the GNU General Public License (GPL).
> +For source code "Two Clause BSD” (BSD-2-Clause) and
> +for documentation CC-BY-SA-4.0 license is preferred.
> +The modification places no restrictions on the applications which use RTEMS 
> but
> +protects the interests of those who work on RTEMS.
> +
> +`License in RTEMS
> + +license-requirements.html>`__
> +

add the other questions even if their pages are missing, and maybe add
a "TBD" stub or something so someone can provide the answers.

Here would be "Are there Export Restrictions? on RTEMS?"

> +What standards are supported by RTEMS?
> +-
> +
> +The original "Classic" RTEMS API is based on the Real-Time Executive 
> Interface
> +Definition (RTEID) and the Open Real-Time Kernel Interface Definition 
> (ORKID).
> +RTEMS also includes support for POSIX threads and real-time extensions.
> +
> +With the addition of file system infrastructure, RTEMS supports approximately
> +80% of the POSIX 1003.1b-1996 standard. This standard defines the programming
> +interfaces of standard UNIX. This means that much source code that works on
> +UNIX, also works on RTEMS.RTEMS includes a port of the 

Re: [PATCH 1/2] Added FAQ page

[Joel Sherrill]

On Fri, Apr 2, 2021 at 1:50 PM Ayushman Mishra 
wrote:

> Sir, It was given as an issue https://devel.rtems.org/ticket/3958 (
> Review wiki/TBR/Website/FAQ for correct links) for the faq page
> https://devel.rtems.org/wiki/TBR/Website/FAQ


Thanks for confirming that. When Gedare acks the patches as being
ok by him, I will see about removing that page and fixing links to it.

--joel

>
>
> On Sat, Apr 3, 2021 at 12:10 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Fri, Apr 2, 2021 at 1:19 PM Ayushman Mishra 
> wrote:
> >>
> >> Greetings Sir,
> >> I have corrected and send patches regarding FAQ page in user manual.I
> >> was able to build the page on my system and also attached a
> >> screen-shot of the builded page on browser . I have corrected
> >> whitespace consistency and reference links according to other
> >> doc-pages
> >
> >
> > Random question. Is this information from the Wiki or just an update
> > of what was already in rtems-docs? If this obsoletes any information
> > in the wiki, I would like to know so we can remove it.
> >
> >>
> >> . Regarding the issue of cross-link between docs , I had
> >> sent mail on devel mail list
> >> https://lists.rtems.org/pipermail/devel/2021-March/065882.html but
> >> haven't got any response , so few days ago after a little discussion
> >> on discord vijay sir said to post the patch and someone might point it
> >> to a better way if it exists.
> >
> >
> > I don't know if we know the answer to that with Sphinx. If "we" do, then
> > I am not part of that "we".  Hopefully someone will educate us. :)
> >
> > Gedare.. is the new patch OK? It must be in another thread because
> > I don't see it here.
> >
> > --joel
> >>
> >>
> >> On Wed, Mar 24, 2021 at 1:05 AM Gedare Bloom  wrote:
> >> >
> >> > Did you build the docs and verify they look good?
> >> >
> >> > On Tue, Mar 23, 2021 at 12:44 PM Ayushman Mishra
> >> >  wrote:
> >> > >
> >> > > ---
> >> > >  user/bld/index.rst   |   4 +-
> >> > >  user/overview/index.rst  |   2 +
> >> > >  user/start/faq.rst   | 255
> +++
> >> > >  user/start/index.rst |   1 +
> >> > >  user/support/support-project.rst |   2 +
> >> > >  5 files changed, 263 insertions(+), 1 deletion(-)
> >> > >  create mode 100644 user/start/faq.rst
> >> > >
> >> > > diff --git a/user/bld/index.rst b/user/bld/index.rst
> >> > > index ebedf5a..a8a8a4f 100644
> >> > > --- a/user/bld/index.rst
> >> > > +++ b/user/bld/index.rst
> >> > > @@ -82,7 +82,7 @@ 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 <
> https://docs.rtems.org/branches/master/eng/build-system.rst>`_
> >> > > +`RTEMS Software Engineering <
> https://docs.rtems.org/branches/master/eng/build-system.html>`_
> >> > >  guide.
> >> > >
> >> > >  Help
> >> > > @@ -283,6 +283,8 @@ example configuration file, building of the
> tests is enabled for the
> >> > >  [sparc/erc32]
> >> > >
> >> > >  [riscv/griscv]
> >> > > +
> >> > > +.. _Autoconf_migration:
> >> > this looks like something should be a cleanup separate submission.
> >> >
> >> > I think the tags are usually directly translated from the section
> >> > names with camelcase?
> >> > _Migration_from_AutoconfAutomake
> >> > or so? check other docs for consistency/guidance.
> >> >
> >> > >
> >> > >  Migration from Autoconf/Automake
> >> > >  
> >> > > diff --git a/user/overview/index.rst b/user/overview/index.rst
> >> > > index 550724a..0703ede 100644
> >> > > --- a/user/overview/index.rst
> >> > > +++ b/user/overview/index.rst
> >> > > @@ -20,6 +20,8 @@ You are someone looking for a real-time operating
> system.  This document
> >> > >
> >> > >  - helps you to build an example application on top of RTEMS.
> >> > >
> >> > > +.. _Features:
> >> > > +
> >> > >  Features
> >> > >  
> >> > >
> >> > > diff --git a/user/start/faq.rst b/user/start/faq.rst
> >> > > new file mode 100644
> >> > > index 000..da11ca4
> >> > > --- /dev/null
> >> > > +++ b/user/start/faq.rst
> >> > > @@ -0,0 +1,255 @@
> >> > > +Frequently Asked Questions
> >> > > +==
> >> > > +
> >> > > +What is RTEMS ?
> >> > > +---
> >> > > +
> >> > > +RTEMS is an open source real-time executive which provides a high
> performance
> >> > > +environment for embedded real-time applications including many
> features.
> >> > > +
> >> > > +The RTEMS Project is the umbrella term used to describe the
> collection of
> >> > > +individuals, companies, universities, and research institutions
> that collectively
> >> > > +maintain and enhance the RTEMS software base.
> >> > > +
> >> > > +RTEMS is designed to support applications with the most stringent
> 

Re: [PATCH 1/2] Added FAQ page

[Ayushman Mishra]

Sir, It was given as an issue https://devel.rtems.org/ticket/3958 (
Review wiki/TBR/Website/FAQ for correct links) for the faq page
https://devel.rtems.org/wiki/TBR/Website/FAQ

On Sat, Apr 3, 2021 at 12:10 AM Joel Sherrill  wrote:
>
>
>
> On Fri, Apr 2, 2021 at 1:19 PM Ayushman Mishra  
> wrote:
>>
>> Greetings Sir,
>> I have corrected and send patches regarding FAQ page in user manual.I
>> was able to build the page on my system and also attached a
>> screen-shot of the builded page on browser . I have corrected
>> whitespace consistency and reference links according to other
>> doc-pages
>
>
> Random question. Is this information from the Wiki or just an update
> of what was already in rtems-docs? If this obsoletes any information
> in the wiki, I would like to know so we can remove it.
>
>>
>> . Regarding the issue of cross-link between docs , I had
>> sent mail on devel mail list
>> https://lists.rtems.org/pipermail/devel/2021-March/065882.html but
>> haven't got any response , so few days ago after a little discussion
>> on discord vijay sir said to post the patch and someone might point it
>> to a better way if it exists.
>
>
> I don't know if we know the answer to that with Sphinx. If "we" do, then
> I am not part of that "we".  Hopefully someone will educate us. :)
>
> Gedare.. is the new patch OK? It must be in another thread because
> I don't see it here.
>
> --joel
>>
>>
>> On Wed, Mar 24, 2021 at 1:05 AM Gedare Bloom  wrote:
>> >
>> > Did you build the docs and verify they look good?
>> >
>> > On Tue, Mar 23, 2021 at 12:44 PM Ayushman Mishra
>> >  wrote:
>> > >
>> > > ---
>> > >  user/bld/index.rst   |   4 +-
>> > >  user/overview/index.rst  |   2 +
>> > >  user/start/faq.rst   | 255 +++
>> > >  user/start/index.rst |   1 +
>> > >  user/support/support-project.rst |   2 +
>> > >  5 files changed, 263 insertions(+), 1 deletion(-)
>> > >  create mode 100644 user/start/faq.rst
>> > >
>> > > diff --git a/user/bld/index.rst b/user/bld/index.rst
>> > > index ebedf5a..a8a8a4f 100644
>> > > --- a/user/bld/index.rst
>> > > +++ b/user/bld/index.rst
>> > > @@ -82,7 +82,7 @@ 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 
>> > > `_
>> > > +`RTEMS Software Engineering 
>> > > `_
>> > >  guide.
>> > >
>> > >  Help
>> > > @@ -283,6 +283,8 @@ example configuration file, building of the tests is 
>> > > enabled for the
>> > >  [sparc/erc32]
>> > >
>> > >  [riscv/griscv]
>> > > +
>> > > +.. _Autoconf_migration:
>> > this looks like something should be a cleanup separate submission.
>> >
>> > I think the tags are usually directly translated from the section
>> > names with camelcase?
>> > _Migration_from_AutoconfAutomake
>> > or so? check other docs for consistency/guidance.
>> >
>> > >
>> > >  Migration from Autoconf/Automake
>> > >  
>> > > diff --git a/user/overview/index.rst b/user/overview/index.rst
>> > > index 550724a..0703ede 100644
>> > > --- a/user/overview/index.rst
>> > > +++ b/user/overview/index.rst
>> > > @@ -20,6 +20,8 @@ You are someone looking for a real-time operating 
>> > > system.  This document
>> > >
>> > >  - helps you to build an example application on top of RTEMS.
>> > >
>> > > +.. _Features:
>> > > +
>> > >  Features
>> > >  
>> > >
>> > > diff --git a/user/start/faq.rst b/user/start/faq.rst
>> > > new file mode 100644
>> > > index 000..da11ca4
>> > > --- /dev/null
>> > > +++ b/user/start/faq.rst
>> > > @@ -0,0 +1,255 @@
>> > > +Frequently Asked Questions
>> > > +==
>> > > +
>> > > +What is RTEMS ?
>> > > +---
>> > > +
>> > > +RTEMS is an open source real-time executive which provides a high 
>> > > performance
>> > > +environment for embedded real-time applications including many features.
>> > > +
>> > > +The RTEMS Project is the umbrella term used to describe the collection 
>> > > of
>> > > +individuals, companies, universities, and research institutions that 
>> > > collectively
>> > > +maintain and enhance the RTEMS software base.
>> > > +
>> > > +RTEMS is designed to support applications with the most stringent 
>> > > real-time
>> > > +requirements while being compatible with open standards such as POSIX.
>> > > +RTEMS includes optional functional features such as TCP/IP and various 
>> > > file
>> > > +systems while still offering minimum executable sizes under 20 KB in 
>> > > useful
>> > > +configurations.
>> > > +
>> > > +:ref:`More Features`
>> > > +
>> > > +Where can I get RTEMS ?
>> > > 

Re: [PATCH 1/2] Added FAQ page

[Joel Sherrill]

On Fri, Apr 2, 2021 at 1:19 PM Ayushman Mishra 
wrote:

> Greetings Sir,
> I have corrected and send patches regarding FAQ page in user manual.I
> was able to build the page on my system and also attached a
> screen-shot of the builded page on browser . I have corrected
> whitespace consistency and reference links according to other
> doc-pages


Random question. Is this information from the Wiki or just an update
of what was already in rtems-docs? If this obsoletes any information
in the wiki, I would like to know so we can remove it.


> . Regarding the issue of cross-link between docs , I had
> sent mail on devel mail list
> https://lists.rtems.org/pipermail/devel/2021-March/065882.html but
> haven't got any response , so few days ago after a little discussion
> on discord vijay sir said to post the patch and someone might point it
> to a better way if it exists.
>

I don't know if we know the answer to that with Sphinx. If "we" do, then
I am not part of that "we".  Hopefully someone will educate us. :)

Gedare.. is the new patch OK? It must be in another thread because
I don't see it here.

--joel

>
> On Wed, Mar 24, 2021 at 1:05 AM Gedare Bloom  wrote:
> >
> > Did you build the docs and verify they look good?
> >
> > On Tue, Mar 23, 2021 at 12:44 PM Ayushman Mishra
> >  wrote:
> > >
> > > ---
> > >  user/bld/index.rst   |   4 +-
> > >  user/overview/index.rst  |   2 +
> > >  user/start/faq.rst   | 255 +++
> > >  user/start/index.rst |   1 +
> > >  user/support/support-project.rst |   2 +
> > >  5 files changed, 263 insertions(+), 1 deletion(-)
> > >  create mode 100644 user/start/faq.rst
> > >
> > > diff --git a/user/bld/index.rst b/user/bld/index.rst
> > > index ebedf5a..a8a8a4f 100644
> > > --- a/user/bld/index.rst
> > > +++ b/user/bld/index.rst
> > > @@ -82,7 +82,7 @@ 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 <
> https://docs.rtems.org/branches/master/eng/build-system.rst>`_
> > > +`RTEMS Software Engineering <
> https://docs.rtems.org/branches/master/eng/build-system.html>`_
> > >  guide.
> > >
> > >  Help
> > > @@ -283,6 +283,8 @@ example configuration file, building of the tests
> is enabled for the
> > >  [sparc/erc32]
> > >
> > >  [riscv/griscv]
> > > +
> > > +.. _Autoconf_migration:
> > this looks like something should be a cleanup separate submission.
> >
> > I think the tags are usually directly translated from the section
> > names with camelcase?
> > _Migration_from_AutoconfAutomake
> > or so? check other docs for consistency/guidance.
> >
> > >
> > >  Migration from Autoconf/Automake
> > >  
> > > diff --git a/user/overview/index.rst b/user/overview/index.rst
> > > index 550724a..0703ede 100644
> > > --- a/user/overview/index.rst
> > > +++ b/user/overview/index.rst
> > > @@ -20,6 +20,8 @@ You are someone looking for a real-time operating
> system.  This document
> > >
> > >  - helps you to build an example application on top of RTEMS.
> > >
> > > +.. _Features:
> > > +
> > >  Features
> > >  
> > >
> > > diff --git a/user/start/faq.rst b/user/start/faq.rst
> > > new file mode 100644
> > > index 000..da11ca4
> > > --- /dev/null
> > > +++ b/user/start/faq.rst
> > > @@ -0,0 +1,255 @@
> > > +Frequently Asked Questions
> > > +==
> > > +
> > > +What is RTEMS ?
> > > +---
> > > +
> > > +RTEMS is an open source real-time executive which provides a high
> performance
> > > +environment for embedded real-time applications including many
> features.
> > > +
> > > +The RTEMS Project is the umbrella term used to describe the
> collection of
> > > +individuals, companies, universities, and research institutions that
> collectively
> > > +maintain and enhance the RTEMS software base.
> > > +
> > > +RTEMS is designed to support applications with the most stringent
> real-time
> > > +requirements while being compatible with open standards such as POSIX.
> > > +RTEMS includes optional functional features such as TCP/IP and
> various file
> > > +systems while still offering minimum executable sizes under 20 KB in
> useful
> > > +configurations.
> > > +
> > > +:ref:`More Features`
> > > +
> > > +Where can I get RTEMS ?
> > > +-
> > > +
> > > +:ref:`Downloading RTEMS`
> > > +
> > > +
> > > +What does RTEMS stand for ?
> > > +-
> > > +
> > > +RTEMS is an an acronym for the Real-Time Executive for Multiprocessor
> Systems.
> > an an
> >
> > > +
> > > +Initially RTEMS stood for the Real-Time Executive for Missile Systems
> but as it
> > > +became clear that 

[PATCH rtems-docs v2 2/2] Corrected link

[Ayushman Mishra]

---
 eng/stakeholders.rst | 4 +++-
 user/bld/index.rst   | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/eng/stakeholders.rst b/eng/stakeholders.rst
index 756c462..a4413cf 100644
--- a/eng/stakeholders.rst
+++ b/eng/stakeholders.rst
@@ -10,4 +10,6 @@ You are a potential RTEMS stakeholder.  RTEMS is a community 
based free and open
 source project.  All users are treated as stakeholders.  It is hoped that as
 stakeholders, users will contribute to the project, sponsor core developers, 
and
 help fund the infrastructure required to host and manage the project.  Please
-have a look at the *Support and Contributing* chapter of the :r:url:`user`.
+have a look at the `Support and Contributing chapter 
+`__ 
+of the *User manual*.
diff --git a/user/bld/index.rst b/user/bld/index.rst
index 0cccde2..47a84b0 100644
--- a/user/bld/index.rst
+++ b/user/bld/index.rst
@@ -82,7 +82,7 @@ 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 
`_
+`RTEMS Software Engineering 
`_
 guide.
 
 Help
-- 
2.25.1

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

[PATCH rtems-docs v2 1/2] Added FAQ page

[Ayushman Mishra]

---
 user/bld/index.rst   |   2 +
 user/overview/index.rst  |   2 +
 user/start/faq.rst   | 295 +++
 user/start/index.rst |   1 +
 user/support/contrib.rst |  96 +-
 user/support/support-project.rst |   2 +
 6 files changed, 303 insertions(+), 95 deletions(-)
 create mode 100644 user/start/faq.rst

diff --git a/user/bld/index.rst b/user/bld/index.rst
index ebedf5a..0cccde2 100644
--- a/user/bld/index.rst
+++ b/user/bld/index.rst
@@ -284,6 +284,8 @@ example configuration file, building of the tests is 
enabled for the
 
 [riscv/griscv]
 
+.. _Migration_from_AutoconfAutomake:
+
 Migration from Autoconf/Automake
 
 
diff --git a/user/overview/index.rst b/user/overview/index.rst
index 550724a..0703ede 100644
--- a/user/overview/index.rst
+++ b/user/overview/index.rst
@@ -20,6 +20,8 @@ You are someone looking for a real-time operating system.  
This document
 
 - helps you to build an example application on top of RTEMS.
 
+.. _Features:
+
 Features
 
 
diff --git a/user/start/faq.rst b/user/start/faq.rst
new file mode 100644
index 000..910ef8b
--- /dev/null
+++ b/user/start/faq.rst
@@ -0,0 +1,295 @@
+Frequently Asked Questions
+==
+
+What is RTEMS ?
+---
+
+RTEMS is an open source real-time executive which provides a high performance 
+environment for embedded real-time applications including many features.
+
+The RTEMS Project is the umbrella term used to describe the collection of 
+individuals, companies, universities, and research institutions that 
collectively
+maintain and enhance the RTEMS software base.
+
+RTEMS is designed to support applications with the most stringent real-time 
+requirements while being compatible with open standards such as POSIX. 
+RTEMS includes optional functional features such as TCP/IP and various file 
+systems while still offering minimum executable sizes under 20 KB in useful 
+configurations.
+
+:ref:`More Features`
+
+Where can I ​get RTEMS ?
+-
+
+:ref:`Downloading RTEMS`
+
+What does RTEMS stand for ?
+-
+
+RTEMS is an an acronym for the Real-Time Executive for Multiprocessor Systems.
+
+Initially RTEMS stood for the Real-Time Executive for Missile Systems but as it
+became clear that the application domains that could use RTEMS extended far 
+beyond missiles, the "M" changed to mean Military. When maintenance of RTEMS 
+transferred to OAR, the "M" was changed again to Multiprocessor.
+
+At one point, there were both Ada and C implementations of RTEMS. 
+Version 3.2.1 was the last RTEMS version to have implementations in both 
+languages. Supporting the Classic API Ada implementation was painful and 
fraught
+with compiler specific pitfalls. With version 3.5.x, the POSIX API was added as
+the means to support the GNU Ada Translator (GNAT). This effectively 
eliminated 
+the need for an implementation in Ada as the C implementation could 
effectively 
+support both languages.
+
+Are there restrictions on the ​RTEMS License ?
+
+
+RTEMS RTEMS is licensed under a combination of permissive licenses and a 
+modified version of the GNU General Public License (GPL).
+For source code "Two Clause BSD” (BSD-2-Clause) and
+for documentation CC-BY-SA-4.0 license is preferred.
+The modification places no restrictions on the applications which use RTEMS but
+protects the interests of those who work on RTEMS.
+
+`License in RTEMS
+`__
+
+What standards are supported by RTEMS?
+-
+
+The original "Classic" RTEMS API is based on the Real-Time Executive Interface 
+Definition (RTEID) and the Open Real-Time Kernel Interface Definition (ORKID). 
+RTEMS also includes support for POSIX threads and real-time extensions.
+
+With the addition of file system infrastructure, RTEMS supports approximately 
+80% of the POSIX 1003.1b-1996 standard. This standard defines the programming 
+interfaces of standard UNIX. This means that much source code that works on 
+UNIX, also works on RTEMS.RTEMS includes a port of the FreeBSD TCP/IP stack and
+thus supports BSD sockets. It also includes support for numerous networking 
+clients (DHCP, TFTP, NFS, etc.) and servers (FTPD, HTTPD, etc.).
+
+What processors is RTEMS available for ?
+--
+
+:ref:`Architectures in RTEMS`
+
+Are there similar commercial products ?
+
+
+`Some Real time operating system similar to RTEMS 
+`__ 
+
+How can I obtain ​RTEMS support ?
+-
+

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Vijay Kumar Banerjee]

On Fri, Apr 2, 2021 at 2:25 AM Robin Müller 
wrote:
>
> Hi Vijay,
>
> It looks interesting, but I am not really a LwIP expert. I might look
into it once I have more time in 1-2 weeks.
> I only have a BBB and the STM32H7 as test HW right now, but I guess this
is a good starting point.
That indeed is a good starting point.

> Does this mean that the lwIP repository contains the architecture
specific sources shown above? (so the DMA descriptors basically and maybe
the LAN device driver).
Yes, The architecture-specific sources (like the LAN driver) will go to the
lwip repository. The repository isn't really that well structured yet but I
would be working on getting it in shape and there's also interest from a
GSoC student, so this might come in shape with combined efforts. :)

>The lwIP support would then be built as part of the BSP?

The BSP would be built without any specific network stack. The network
stack is supposed to be built separately and then used with the BSP, which
means all the network-related drives go into respective network stacks
(lwip is one of these 3 network stacks). So far this is the plan and the
legacy network drivers have already been moved to its own separate
repository, so we'll take a similar approach for lwip as well

>And would it use the mainloop mode or the OS mode? The STM32 example I
implemented uses the mainloop mode with NO_SYS defined to 1, so I am not
familiar with the OS mode, but I guess it would make sense to use the OS
mode, porting it to RTEMS.

Yes, it would make sense to use the OS mode. I guess the NO_SYS needs to be
set to 0, which means it'll use the sys_arch definitions. We have an RTEMS
port for the sys_arch, done by Pavel Pisa. You can find it here:
https://git.rtems.org/vijay/rtems-lwip.git/tree/lwip/ports/os/rtems/arch/sys_arch.h
. It could be possible that all the drivers use this port and extend the
sys_arch module according to the requirements, but I'm not totally sure if
or how that'll work out. If each driver needs to have a separate sys_arch
file, we'll have to add it along with the drivers and find a way to select
the correct sources for the given bsp. I think that using an ini or yaml
config file to define the requirements would be a clean solution to teach
waf which modules to build.

Thank you for working on getting lwip integrated with stm32 h7. This would
be a great start for the rtems-lwip and I'm happy to work with you to get
it merged to that repository. I have also found a BBB driver for lwip and
I'll try to integrate that as well. We'll probably be able to get hardware
tests from these two boards soon. :)


Best regards,
Vijay

>
> Kind Regards
> Robin
>
>
> On Mon, 29 Mar 2021 at 22:25, Vijay Kumar Banerjee 
wrote:
>>
>> On Mon, Mar 29, 2021 at 9:52 AM Gedare Bloom  wrote:
>> >
>> > On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller <
robin.muelle...@gmail.com> wrote:
>> > >
>> > > This patch adds support for the STM32H743ZI-Nucleo board
>> > > variation. This currently works by setting the STM32H743ZI_NUCLEO
>> > > flag in the config.ini flag
>> > >
>> > > It also adds basic lwIP support which can be enabled
>> > > with the flag STM32H7_ADD_LWIP. This enables certain functionalities
>> > > required for lwIP to work properly
>> > >
>> > > This patch also changes the default implementation
>> > > of HAL_GetTick to return the system tick by forwarding the call
>> > > to the respective RTEMS function.
>> > >
>> > > ---
>> > >  bsps/arm/stm32h7/console/console-usart3-cfg.c | 21 
>> > >  bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c  | 16 -
>> > >  .../stm32h7/include/Legacy/stm32_hal_legacy.h |  4 +++-
>> > >  bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
>> > >  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h |  1 +
>> > >  bsps/arm/stm32h7/start/bspstart.c |  2 +-
>> > >  bsps/arm/stm32h7/start/stm32h7-hal-eth.c  |  3 +--
>> > >  spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  4 
>> > >  spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
>> > >  spec/build/bsps/arm/stm32h7/optlwip.yml   | 24
+++
>> > >  10 files changed, 88 insertions(+), 11 deletions(-)
>> > >  create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
>> > >  create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
>> > >
>> > > diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c
b/bsps/arm/stm32h7/console/console-usart3-cfg.c
>> > > index b40f6da5aa..dc552610e1 100644
>> > > --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
>> > > +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
>> > > @@ -25,12 +25,32 @@
>> > >   * POSSIBILITY OF SUCH DAMAGE.
>> > >   */
>> > >
>> > > +#ifdef __rtems__
>> > > +#include 
>> > > +#endif
>> > > +
>> > >  #ifdef HAVE_CONFIG_H
>> > >  #include "config.h"
>> > >  #endif
>> > >
>> > >  #include 
>> > >
>> > > +#if STM32H743ZI_NUCLEO == 1
>> > > +const stm32h7_uart_config stm32h7_usart3_config = {
>> > > +  .gpio = {
>> > > +.regs = 

Re: GSoC Project - Beagle BSP Projects

[Christian Mauderer]

On 02/04/2021 08:36, Ahamed Husni wrote:

>     Yes, this seems like an area that can be chipped away at, with a
>     strong plan of activities. My concern would be whether it is about
>     writing code or not?
> 
> 
> After completing the above milestones, if we have more time I can start 
> to work on

> the Mass storage support.
>


I would suggest to put _more_ into the proposal and make it clear that
the later points depend on whether there is enough time or not.

@Gedare: The time and effort for that project is really hard to
estimate
in my point of view. Do you have an idea how we could handle that?


So do I have to include mass storage support into the project schedule or
should I prepare the schedule for Ethernet, Serial and add the list of
possible advances and say that I'll work on them if there is enough time?


I would suggest to include it. I'm quite sure that there is enough time.



Most likely we would have to put some further open points at the end of
that because like I said: Depending on how well it works you might need
anything between a day and three weeks to get CDC Ethernet running.
 From
my first guess, it's maybe a week.

Note that I would expect that you will need a debugger and the RTEMS
event recording for this kind of project.


CDC Serial should be only a small step as soon as CDC Ethernet is
running.


I don't have a JTAG debugger now. I'll get that set up asap.


> USB OTG would be a nice area. But that will be less writing a driver
>     for
>     Beagle but more finding out how that works with libbsd and finding a
>     good way to configure it. I once put a few hours into it didn't take
>     too
>     much time till a PC detected an USB device (see
> https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce

 >   
  >).
>     Basically it's about importing the "usb_template" stuff and finding a
>     way to configure it in libbsd.


I'm trying to build and test this branch. I had trouble with building 
the libbsd.


The branch is very old. Most likely it won't build with a current 
toolchain and a current RTEMS. You might want to try to rebase the last 
two patches onto an up to date libbsd.


So I started to build the tools and kernel from scratch with the RSB 
master, using

beaglebone black bset. It gives me the following error.
Error log: https://pastebin.com/NYZRej1B 

Build command

../source-builder/sb-set-builder --log=beagle.txt
--prefix=$BASE/rtems/6 bsps/beagleboneblack.bset


For development I would suggest to build only the toolchain using RSB. 
After that you should build the BSP and libbsd manually. You will have 
to recompile the BSP and libbsd quite often and it's a lot more 
convenient to do that without touching RSB every time.


I would suggest to use some simple scripts or a Makefile for that. 
Something like


https://gitlab.com/c-mauderer/rtems-bbb/-/blob/master/Makefile

Note that the repo containing that Makefile is no official one and it is 
unstable. Most of the time I use it for testing stuff.




What would be the steps to configure the USB OTG driver from libbsd to BBB.
I would like to try it out. Please guide me on this.


I think that's most of the problem of the GSoC ;-)

Basically it's the following steps:

- Importing the relevant parts (should be the usb_template stuff) from 
FreeBSD into libbsd. That's basically what the first commit on the 
branch does. Take a look at the CONTRIBUTING.md file in libbsd for 
details about the import process: 
https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md#n158


- Enable them for Beagle. That's the second commit on the branch.

- Somehow configure the USB OTG stuff. Like I said: That's the tricky 
part. It has something to do with the usb_temp_init functions. But I 
didn't manage to get it working in an hour or so and stopped trying 
after that. So finding out how to configure and set up the stuff will be 
part of your Project.


Best regards

Christian



Best regards,

On Fri, Mar 26, 2021 at 8:17 PM Christian MAUDERER 
> wrote:


Hello Ahamed,

Am 26.03.21 um 15:31 schrieb Ahamed Husni:
 >     USB OTG would be a nice area. But that will be less writing a
driver
 >     for
 >     Beagle but more finding out how that works with libbsd and
finding a
 >     good way to configure it. I once put a few hours into it
didn't take
 >     too
 >     much time till a PC detected an USB device (see
 > https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce

Re: GSOC project: #4334 Replace Mongoose with Civetweb

[Gedare Bloom]

On Thu, Apr 1, 2021 at 10:13 PM Ayushman Mishra
 wrote:
>
> Respected Sir,
>
> 1. I successfully build and installed the tool suit in rtems6
> (../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6
> devel/qemu.bset) , this time all executable related to qemu
This is building and installing the qemu.bset, that just means qemu
stuff gets installed

> (qemu-system-arm) were installed in 6/bin but the gcc file
> (arm-rtems6-gcc) and other arm-rtems- related files weren't installed
You would need to do something like 6/rtems-arm just like you did with 5.

> which is causing problem in building xilinx_zynq_a9_qemu bsp  (Could
> not find the program ['arm-rtems6-gcc'] ). This problem didn't occur
> and I was able to build the bsp when I installed tools in rtems5 ( $
> ../source-builder/sb-set-builder --prefix="$HOME/quick-start/rtems/5"
> 5/rtems-arm ) but there qemu-system-arm and other qemu- files weren't
> installed . I don't why is the problem is occurring but very
> enthusiast in solving this if you can please provide a little help.
>
> 2, I had drawn my conclusion regarding placement of civetweb package
> after reading some of the initial discussion regarding replacing
> "mongoose with civetweb" on devel mailing list
> (https://lists.rtems.org/pipermail/devel/2016-April/042581.html) but
> after going through entire discussion I am getting confused weather to
> provide it as an external 3rd party package via the RSB (which I now
> think is a good idea) or place it in a separate repository. Also after
I'd prefer a 3rd party package, with any code fixes/changes submitted
to them that belong in civetweb.

> reading through discussion I think one other task of project would be
> to 1.make build configuration for civetweb as it uses make Cmake and
> Makefile build system where as rtems now uses waf build system and 2.
it is better if you teach RSB how to build civetweb exactly how it is
meant to be built, e.g., using cmake system.

> to integrate tests provided by civetweb into rtems.
Better yet, to compile the civetweb tests as part of the civetweb
package. testing network applications is a bit tricky.

> Sir, I would be highly grateful if you can provide some documentation
> to get more information regarding  the current architecture and build
> configuration of web-server in rtems as most of the discussions are
> pretty old and I wanted to start writing proposal for this project.
> thanks , ayushman
>
> On Wed, Mar 31, 2021 at 9:28 PM Gedare Bloom  wrote:
> >
> > On Wed, Mar 31, 2021 at 3:18 AM Ayushman Mishra
> >  wrote:
> > >
> > > Sir,
> > > I am trying to integrate mongoose web-server in simple rtems
> > > application (https://devel.rtems.org/wiki/Developer/Mongoose_Web_Server),
> > > for that I have to configure networking in rtems. I am using
> > > xilinx_zynq_a9_qemu for simulation bsp and following steps given here
> > > https://git.rtems.org/rtems-libbsd/tree/README.md but after doing
> > > ./waf install , i was not able to find qemu-system-arm in any
> > > directory , I did sudo apt-get install qemu but then also
> > > qemu-system-arm was not found . I discussed in discord channel and
> > > started using rsb recipe devel/qemu4 (
> > > $ ../source-builder/sb-set-builder --prefix=
> > > devel/qemu4.bset ) present in branch 5 of rsb ( since master branch
> > > doesn't have qemu4.bset ) but after building for few minutes it gave
> > > BUILD FAILED error
> >
> > bare/devel/qemu.bset should get you a working version on qemu v5, I
> > would guess that should work.
> >
> > > ( Last lines of error report:
> > >  ../../glib-2.46.2/gio/gdbusauth.c: In function '_g_dbus_auth_run_server':
> > > ../../glib-2.46.2/gio/gdbusauth.c:1295:11: error: '%s' directive
> > > argument is null [-Werror=format-overflow=]
> > >  1295 |   debug_print ("SERVER: WaitingForBegin, read '%s'", 
> > > line);
> > >   |   ^~~~
> > > cc1: some warnings being treated as errors
> > > make[4]: *** [Makefile:3624: libgio_2_0_la-gdbusauth.lo] Error 1
> > > make[4]: *** Waiting for unfinished jobs
> > > make[4]: Leaving directory
> > > '/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build/gio'
> > > make[3]: *** [Makefile:4094: all-recursive] Error 1
> > > make[3]: Leaving directory
> > > '/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build/gio'
> > > make[2]: *** [Makefile:1861: all] Error 2
> > > make[2]: Leaving directory
> > > '/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build/gio'
> > > make[1]: *** [Makefile:1212: all-recursive] Error 1
> > > make[1]: Leaving directory
> > > '/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build'
> > > make: *** [Makefile:854: all] Error 2
> > > shell cmd failed: /bin/sh -ex
> > > /home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/do-build
> > > error: building 

GSoC 2021 - Raspberry Pi projects

[Pranav Dangi]

Hi everyone,
I am keen on working on the Raspberry Pi project #2899
. However, the ticket and also the
TODOs in the github README
 for the
same haven't been updated since 4 years, so I am not sure what work needs
to be done specifically. For example, the README lists support for SPI and
GPIO in TODO but apparently support for them has already been added.
Moreover given the smaller GSoC, I'd like a mentor to elaborate on the
potential scope of the project.
>From what I could understand so far, I think I can continue/complete the
previous GSoC projects(the situation seems fine on drivers for the initial
Pis), or work on the support for Pi 3 or 4.
PS: I only have spare Pi Zeroes at home, so I'll be getting the hardware
for the specific project this week depending on what aspect I have to work
on.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Robin Müller]

 The change with void HAL_ETH_MspInit(ETH_HandleTypeDef *heth) was just
that most
other function definitions I saw were on one line so I assumed this was a
little formatting mistake. I can discard the change if this was
intentional.

I can add #ifndef __rtems__ for the section with the legacy defines as well.
Kind Regards
Robin

On Mon, 29 Mar 2021 at 17:52, Gedare Bloom  wrote:

> On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller 
> wrote:
> >
> > This patch adds support for the STM32H743ZI-Nucleo board
> > variation. This currently works by setting the STM32H743ZI_NUCLEO
> > flag in the config.ini flag
> >
> > It also adds basic lwIP support which can be enabled
> > with the flag STM32H7_ADD_LWIP. This enables certain functionalities
> > required for lwIP to work properly
> >
> > This patch also changes the default implementation
> > of HAL_GetTick to return the system tick by forwarding the call
> > to the respective RTEMS function.
> >
> > ---
> >  bsps/arm/stm32h7/console/console-usart3-cfg.c | 21 
> >  bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c  | 16 -
> >  .../stm32h7/include/Legacy/stm32_hal_legacy.h |  4 +++-
> >  bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
> >  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h |  1 +
> >  bsps/arm/stm32h7/start/bspstart.c |  2 +-
> >  bsps/arm/stm32h7/start/stm32h7-hal-eth.c  |  3 +--
> >  spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  4 
> >  spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
> >  spec/build/bsps/arm/stm32h7/optlwip.yml   | 24 +++
> >  10 files changed, 88 insertions(+), 11 deletions(-)
> >  create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
> >  create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
> >
> > diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > index b40f6da5aa..dc552610e1 100644
> > --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > @@ -25,12 +25,32 @@
> >   * POSSIBILITY OF SUCH DAMAGE.
> >   */
> >
> > +#ifdef __rtems__
> > +#include 
> > +#endif
> > +
> >  #ifdef HAVE_CONFIG_H
> >  #include "config.h"
> >  #endif
> >
> >  #include 
> >
> > +#if STM32H743ZI_NUCLEO == 1
> > +const stm32h7_uart_config stm32h7_usart3_config = {
> > +  .gpio = {
> > +.regs = GPIOD,
> > +.config = {
> > +  .Pin = GPIO_PIN_8 | GPIO_PIN_9,
> > +  .Mode = GPIO_MODE_AF_PP,
> > +  .Pull = GPIO_NOPULL,
> > +  .Speed = GPIO_SPEED_FREQ_LOW,
> > +  .Alternate = GPIO_AF7_USART3
> > +}
> > +  },
> > +  .irq = USART3_IRQn,
> > +  .device_index = 2
> > +};
> > +#else
> >  const stm32h7_uart_config stm32h7_usart3_config = {
> >.gpio = {
> >  .regs = GPIOB,
> > @@ -45,3 +65,4 @@ const stm32h7_uart_config stm32h7_usart3_config = {
> >.irq = USART3_IRQn,
> >.device_index = 2
> >  };
> > +#endif /*  STM32H743ZI_NUCLEO == 1 */
> > diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > index 4f2634df5b..6c3590bce8 100644
> > --- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > +++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > @@ -146,6 +146,10 @@
> >  /* Includes
> --*/
> >  #include "stm32h7xx_hal.h"
> >
> > +#ifdef __rtems__
> > +#include 
> > +#endif
> > +
> >  /** @addtogroup STM32H7xx_HAL_Driver
> >* @{
> >*/
> > @@ -361,10 +365,10 @@ HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef
> *heth)
> >/*-- MAC, MTL and DMA default Configuration
> */
> >ETH_MACDMAConfig(heth);
> >
> > -#ifndef __rtems__
> > +#if STM32H7_ADD_LWIP == 1
>
> Someone else may be able to address whether we need to disable this
> stuff for 'non-lwip' builds of stm32. There is an ongoing effort to
> collect lwip drivers and lwip build as a library after building rtems,
> so maybe this will move eventually to the lwip driver repo when that
> gets into production.
>
> >/* SET DSL to 64 bit */
> >MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL,
> ETH_DMACCR_DSL_64BIT);
> > -#endif /* __rtems__ */
> > +#endif
> >
> >/* Set Receive Buffers Length (must be a multiple of 4) */
> >if ((heth->Init.RxBuffLen % 0x4U) != 0x0U)
> > @@ -2647,7 +2651,7 @@ static void
> ETH_MAC_MDIO_ClkConfig(ETH_HandleTypeDef *heth)
> >*/
> >  static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
> >  {
> > -#ifndef __rtems__
> > +#if STM32H7_ADD_LWIP == 1
> >ETH_DMADescTypeDef *dmatxdesc;
> >uint32_t i;
> >
> > @@ -2674,7 +2678,7 @@ static void
> ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
> >
> >/* Set Transmit Descriptor Tail pointer */
> >WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
> > -#endif /* __rtems__ */
> > +#endif /* STM32H7_ADD_LWIP == 1 */
> >  }
> >
> >  /**
> > @@ -2686,7 +2690,7 @@ static void
> 

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Robin Müller]

Hi Vijay,

It looks interesting, but I am not really a LwIP expert. I might look into
it once I have more time in 1-2 weeks.
I only have a BBB and the STM32H7 as test HW right now, but I guess this is
a good starting point.
Does this mean that the lwIP repository contains the architecture specific
sources shown above? (so the DMA descriptors basically and maybe the LAN
device driver). The lwIP support would then be built as part of the BSP?
And would it use the mainloop mode or the OS mode? The STM32 example I
implemented uses the mainloop mode with NO_SYS defined to 1, so I am not
familiar with the OS mode, but I guess it would make sense to use the OS
mode, porting it to RTEMS.

Kind Regards
Robin


On Mon, 29 Mar 2021 at 22:25, Vijay Kumar Banerjee  wrote:

> On Mon, Mar 29, 2021 at 9:52 AM Gedare Bloom  wrote:
> >
> > On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller 
> wrote:
> > >
> > > This patch adds support for the STM32H743ZI-Nucleo board
> > > variation. This currently works by setting the STM32H743ZI_NUCLEO
> > > flag in the config.ini flag
> > >
> > > It also adds basic lwIP support which can be enabled
> > > with the flag STM32H7_ADD_LWIP. This enables certain functionalities
> > > required for lwIP to work properly
> > >
> > > This patch also changes the default implementation
> > > of HAL_GetTick to return the system tick by forwarding the call
> > > to the respective RTEMS function.
> > >
> > > ---
> > >  bsps/arm/stm32h7/console/console-usart3-cfg.c | 21 
> > >  bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c  | 16 -
> > >  .../stm32h7/include/Legacy/stm32_hal_legacy.h |  4 +++-
> > >  bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
> > >  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h |  1 +
> > >  bsps/arm/stm32h7/start/bspstart.c |  2 +-
> > >  bsps/arm/stm32h7/start/stm32h7-hal-eth.c  |  3 +--
> > >  spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  4 
> > >  spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
> > >  spec/build/bsps/arm/stm32h7/optlwip.yml   | 24 +++
> > >  10 files changed, 88 insertions(+), 11 deletions(-)
> > >  create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
> > >  create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
> > >
> > > diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > > index b40f6da5aa..dc552610e1 100644
> > > --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > > +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > > @@ -25,12 +25,32 @@
> > >   * POSSIBILITY OF SUCH DAMAGE.
> > >   */
> > >
> > > +#ifdef __rtems__
> > > +#include 
> > > +#endif
> > > +
> > >  #ifdef HAVE_CONFIG_H
> > >  #include "config.h"
> > >  #endif
> > >
> > >  #include 
> > >
> > > +#if STM32H743ZI_NUCLEO == 1
> > > +const stm32h7_uart_config stm32h7_usart3_config = {
> > > +  .gpio = {
> > > +.regs = GPIOD,
> > > +.config = {
> > > +  .Pin = GPIO_PIN_8 | GPIO_PIN_9,
> > > +  .Mode = GPIO_MODE_AF_PP,
> > > +  .Pull = GPIO_NOPULL,
> > > +  .Speed = GPIO_SPEED_FREQ_LOW,
> > > +  .Alternate = GPIO_AF7_USART3
> > > +}
> > > +  },
> > > +  .irq = USART3_IRQn,
> > > +  .device_index = 2
> > > +};
> > > +#else
> > >  const stm32h7_uart_config stm32h7_usart3_config = {
> > >.gpio = {
> > >  .regs = GPIOB,
> > > @@ -45,3 +65,4 @@ const stm32h7_uart_config stm32h7_usart3_config = {
> > >.irq = USART3_IRQn,
> > >.device_index = 2
> > >  };
> > > +#endif /*  STM32H743ZI_NUCLEO == 1 */
> > > diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > > index 4f2634df5b..6c3590bce8 100644
> > > --- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > > +++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > > @@ -146,6 +146,10 @@
> > >  /* Includes
> --*/
> > >  #include "stm32h7xx_hal.h"
> > >
> > > +#ifdef __rtems__
> > > +#include 
> > > +#endif
> > > +
> > >  /** @addtogroup STM32H7xx_HAL_Driver
> > >* @{
> > >*/
> > > @@ -361,10 +365,10 @@ HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef
> *heth)
> > >/*-- MAC, MTL and DMA default Configuration
> */
> > >ETH_MACDMAConfig(heth);
> > >
> > > -#ifndef __rtems__
> > > +#if STM32H7_ADD_LWIP == 1
> >
> > Someone else may be able to address whether we need to disable this
> > stuff for 'non-lwip' builds of stm32. There is an ongoing effort to
> > collect lwip drivers and lwip build as a library after building rtems,
> > so maybe this will move eventually to the lwip driver repo when that
> > gets into production.
> >
> Hi,
>
> Yes, we're moving all the network stacks out of RTEMS so that a user
> can choose their preferred network stack to work with RTEMS. The LWIP
> repository is in initial state and it is gradually starting to include
> the drivers. This lwip patch would be a great 

Re: GSoC Project - Beagle BSP Projects

[Ahamed Husni]

>
> > Yes, this seems like an area that can be chipped away at, with a
>> > strong plan of activities. My concern would be whether it is about
>> > writing code or not?
>> >
>> >
>> > After completing the above milestones, if we have more time I can start
>> > to work on
>> > the Mass storage support.
>> >
>>
>
> I would suggest to put _more_ into the proposal and make it clear that
> the later points depend on whether there is enough time or not.
>
> @Gedare: The time and effort for that project is really hard to estimate
> in my point of view. Do you have an idea how we could handle that?
>

So do I have to include mass storage support into the project schedule or
should I prepare the schedule for Ethernet, Serial  and add the list of
possible advances and say that I'll work on them if there is enough time?



> Most likely we would have to put some further open points at the end of
> that because like I said: Depending on how well it works you might need
> anything between a day and three weeks to get CDC Ethernet running. From
> my first guess, it's maybe a week.
>
> Note that I would expect that you will need a debugger and the RTEMS
> event recording for this kind of project.
>
>
> CDC Serial should be only a small step as soon as CDC Ethernet is running.
>

I don't have a JTAG debugger now. I'll get that set up asap.


> USB OTG would be a nice area. But that will be less writing a driver
> > for
> > Beagle but more finding out how that works with libbsd and finding a
> > good way to configure it. I once put a few hours into it didn't take
> > too
> > much time till a PC detected an USB device (see
> > https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce
> > ).
> > Basically it's about importing the "usb_template" stuff and finding a
> > way to configure it in libbsd.


I'm trying to build and test this branch. I had trouble with building the
libbsd.
So I started to build the tools and kernel from scratch with the RSB
master, using
beaglebone black bset. It gives me the following error.
Error log: https://pastebin.com/NYZRej1B

Build command

> ../source-builder/sb-set-builder --log=beagle.txt --prefix=$BASE/rtems/6
> bsps/beagleboneblack.bset


What would be the steps to configure the USB OTG driver from libbsd to BBB.
I would like to try it out. Please guide me on this.

Best regards,

On Fri, Mar 26, 2021 at 8:17 PM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Hello Ahamed,
>
> Am 26.03.21 um 15:31 schrieb Ahamed Husni:
> > USB OTG would be a nice area. But that will be less writing a driver
> > for
> > Beagle but more finding out how that works with libbsd and finding a
> > good way to configure it. I once put a few hours into it didn't take
> > too
> > much time till a PC detected an USB device (see
> > https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce
> > ).
> > Basically it's about importing the "usb_template" stuff and finding a
> > way to configure it in libbsd.
> >
> > I think that topic would have to be a bit of an open one: You might
> > work
> > only a day on it and have a working CDC Ethernet afterwards or you
> can
> > need weeks for that. So you should add an open list of possible
> > advanced
> > targets. An OTG device can be:
> >
> > - Ethernet
> > - Serial port
> > - Mass storage
> > - Keyboard / Mouse
> > - Modem
> > - Audio
> > - ...
> >
> > The simplest one will most likely be Ethernet followed by serial
> > port. I
> > would add some of the others (like mass storage) as an extended
> targets.
> >
> > Best regards
> >
> > Christian
> >
> >
> > USB OTG would allow more extended capabilities for the beagle board.
> > To work on the USB OTG devices, what would be the best way?
> > What I understood from what Christian says is,
> >
> >  1. Finding out how USB OTG works with libbsd and finding a
> >   way to configure it for the beagle.
> >  2. Work on CDC Ethernet
> >  3. CDC Ethernet - Example application & Documentation
> >  4. Work on Serial over USB
> >  5. Serial over USB - Example application & Documentation
> >
> > Am I right?
>
> Most likely we would have to put some further open points at the end of
> that because like I said: Depending on how well it works you might need
> anything between a day and three weeks to get CDC Ethernet running. From
> my first guess, it's maybe a week.
>
> Note that I would expect that you will need a debugger and the RTEMS
> event recording for this kind of project.
>
>
> CDC Serial should be only a small step as soon as CDC Ethernet is running.
>
> Mass storage depends on the current implementation for that in FreeBSD.
> It might could be an interesting part.
>
> >
> > Would implementing Ethernet