Re: [PATCH] Add configuration option for single processor applications

[Richi Dubey]

Hi!

Thanks for your review.

Why not just copy how SMP EDF deals with this problem?
>
> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124
> I guess that is the "right way" to put the onus on the application to
> specify their configuration properly.

This seems like the right way and I completely understand. I am going to
use a similar strategy. btw line 125 exceeds the 80 char limit, is that
okay for header files?

I never thought too much about this. I guess, it means we expect the
> scheduler-specific tests do a sufficient job to exercise the scheduler
> implementations that we can rely on the default scheduler to "just
> work" in the other tests. Which makes sense although you have stumbled
> over some scheduler-specific bugs that are uncovered by these
> non-scheduler tests.

Yes, some of the errors in our Strong APA scheduler (code or logic) was
discovered by failing non scheduler tests.

> Documenting your approach to developing and
> debugging a scheduler may help the next person who tries. :) We don't
> have a great place for that kind of guidance, so I guess clear blog
> posts are helpful for now.

Okay, I am on it. *How to write a scheduler: RTEMS edition* coming soon on
https://rtemswithrichi.wordpress.com/ :p


On Thu, Mar 18, 2021 at 2:15 AM Gedare Bloom  wrote:

> Hi Richi,
>
> On Wed, Mar 17, 2021 at 1:06 PM Sebastian Huber
>  wrote:
> >
> > On 17/03/2021 19:00, Richi Dubey wrote:
> >
> > > Thanks for your quick review.
> > >
> > > I think this patch is superfluous. In which scenario do you think
> > > it is
> > > necessary?
> > >
> > > It is from this mail conversation:
> > > https://lists.rtems.org/pipermail/devel/2020-September/061845.html
> > > 
> > > followed by
> > > https://lists.rtems.org/pipermail/devel/2020-September/061846.html
> > > .
> > For the tests you just need a temporary hack.
> > >
> > > Strong APA uses the value of CONFIGURE_MAXIMUM_PROCESSORS in its
> > > declaration
> > > <
> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L260
> >
> > > at cpukit/include/rtems/scheduler.h. This addition would be necessary
> > > to support future SMP schedulers that need to know the number of CPUs
> > > in the system at the time of configuration.
>
> Can you use _CONFIGURE_MAXIMUM_PROCESSORS there?
>
> Why not just copy how SMP EDF deals with this problem?
>
> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124
>
> I guess that is the "right way" to put the onus on the application to
> specify their configuration properly.
>
> > In general, it makes no sense to use an SMP scheduler on a system with
> > just one processor. If you really want to do this, then you have to
> > explicitly define CONFIGURE_MAXIMUM_PROCESSORS to 1 in your application
> > configuration.
> >
>
> I never thought too much about this. I guess, it means we expect the
> scheduler-specific tests do a sufficient job to exercise the scheduler
> implementations that we can rely on the default scheduler to "just
> work" in the other tests. Which makes sense although you have stumbled
> over some scheduler-specific bugs that are uncovered by these
> non-scheduler tests. Documenting your approach to developing and
> debugging a scheduler may help the next person who tries. :) We don't
> have a great place for that kind of guidance, so I guess clear blog
> posts are helpful for now.
>
> -Gedare
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC project: #4334 Replace Mongoose with Civetweb

[Ayushman Mishra]

Thanks a lot for help and information , actually i am trying to setup
mongoose on simple rtems application
(https://devel.rtems.org/wiki/Developer/Mongoose_Web_Server) and for
that right now I am trying to configure networking and file-system in
the application.

On Sun, Mar 21, 2021 at 8:54 PM Joel Sherrill  wrote:
>
>
>
> On Sun, Mar 21, 2021, 4:45 AM Christian Mauderer  wrote:
>>
>> Hello Ayushman,
>>
>> On 21/03/2021 04:15, Ayushman Mishra wrote:
>> > Ayushman
>> > Hello everyone , I am very much interested in taking
>> > https://devel.rtems.org/ticket/4334
>> > as a GSOC 2021 project. I know some basic networking concepts and would 
>> > like to
>> > learn more about it and how its applied to OS like RTEMS , regarding
>> > this I have some questions.
>>
>> Note that the ticket will be more about integrating civetweb into a
>> RTEMS Source Builder (RSB) recipe and finding a way to make it
>> configurable there. Alternative could be some kind of stand alone repo
>> like for littlevgl.
>
>
> Making the civitweb configure options available to RTEMS user is a key point.
>
> It may make sense to do a repo with waf build system and config.ini that maps 
> to their settings.
>
>>
>> civetweb builds on RTEMS nearly out of the box. So don't expect too much
>> C-Code.
>
>
> I set it up recently on Linux for embedding in their application. As you 
> turned on options, it had more dependencies. This would have to be managed 
> with RTEMS.
>
>>
>> I'm not yet sure how much work will be on that ticket. If it is too few
>> for a whole GSoC, you might want to think about reviving the discussion
>> about some useful civetweb parameters (for an embedded system) here:
>>
>>  https://github.com/civetweb/civetweb/pull/297
>
>
> +1
>
> How to present the options to the user and manage their dependencies would be 
> a key part of this.
>>
>>
>>
>>
>> >
>> > 1. After building a simple hello world application how and where should i 
>> > write
>> > configurations of
>> > https://docs.rtems.org/branches/master/networking/using_networking_rtems_app.html
>> > OR  
>> > https://docs.rtems.org/branches/master/user/migration/v4_11-to-v5.html#networking
>> > to start using networking stack in RTEMS .
>>
>> The documentation is currently mostly for the legacy stack. Please
>> ignore most of that. You should focus on a BSP that uses libbsd. The
>> legacy stack and it's documentation will be removed from the main repos
>> soon.
>>
>> > Also I think a simple shell has to be spawned to use networking modules in 
>> > RTEMS
>> > and for getting it this
>> > https://docs.rtems.org/branches/master/shell/configuration_and_init.html#attached-to-a-serial-port
>> > I think could be a simple method and for doing so ( like executing
>> > rtems_shell_init with parameters )
>> > do i have to run the specific test in testsuite or re-run the application
>>
>> There is a "mghttpd01" test in rtems-libbsd which is used for the
>> current fixed version of mongoose that is integrated in RTEMS. I would
>> suggest to use that as a starting point.
>>
>> >
>> > 2. Is there any specific device or bsp needed for running networking
>> > or shell configurations
>> > with file-system in RTEMS
>>
>> Basically you can use every BSP that has network support. A good
>> simulation BSP where you don't need any hardware is xilinx_zynq_a9_qemu:
>>
>> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-with-xilinx-zynq-a9-qemu
>>
>> Best Regards
>>
>> Christian
>>
>> > I would be very thankful if someone can please clarify my doubts and
>> > guide me further
>> > with this project as I am getting lost and don't know how to proceed
>> > after building a simple application.
>> > Thank-you
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> >
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3 1/3] rtems-debugger: Fixed 32bit pointers

[Chris Johns]

On 21/3/21 2:26 am, Joel Sherrill wrote:
> 
> 
> On Sat, Mar 20, 2021, 1:21 AM Gedare Bloom  > wrote:
> 
> Hi Stephen, Joel:
> 
> On Fri, Mar 19, 2021 at 9:35 AM Stephen Clark  > wrote:
> >
> > Using 32bit types like uint32_t for pointers creates issues on 64 bit
> > architectures like AArch64. Replaced occurrences of these with 
> uintptr_t,
> > which will work for both 32 and 64 bit architectures.
> > ---
> >  cpukit/libdebugger/rtems-debugger-server.c | 4 ++--
> >  cpukit/libdebugger/rtems-debugger-target.c | 2 +-
> >  cpukit/libdebugger/rtems-debugger-target.h | 2 +-
> >  3 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/cpukit/libdebugger/rtems-debugger-server.c
> b/cpukit/libdebugger/rtems-debugger-server.c
> > index 975ec23a30..f8c485a794 100644
> > --- a/cpukit/libdebugger/rtems-debugger-server.c
> > +++ b/cpukit/libdebugger/rtems-debugger-server.c
> > @@ -1438,7 +1438,7 @@ remote_read_memory(uint8_t* buffer, int size)
> >    if (comma == NULL)
> >      remote_packet_out_str(r_E01);
> >    else {
> > -    DB_UINT addr;
> > +    uintptr_t addr;
> >      DB_UINT length;
> >      int     r;
> >      addr = hex_decode_uint([1]);
> 
> I still have concerns that just changing the variable types is not
> addressing any possible fundamental type errors that get hidden by
> later type coercion, for example, here we see addr = hex_decode_uint()
> that returns type DB_UINT, so now we have a type mismatch in 64-bit
> targets. Now, maybe it is fine, because the addresses are limited to
> 32-bits in practice, but I would like some discussion of the analysis
> that has been done on these type changes.
> 
> 
> I commented earlier in this thread that Chris needs to comment on the gdb
> protocol. Switching to uintptr_t should be correct but, as you point out,
> whether or not the gdb protocol uses 64 bit addresses in the messages is 
> unknown
> to us both.
> 
> Looking at the gdb manual, it seems to use addr a lot without explaining this 
> point.
> 
> My money says there needs to be a decode address which returns a uintptr_t. 
> And
> that combined with this patch and a review of where the variables are used is
> needed.
> 
> I suspect the answer is in something like remote.c in the gdb source. 
> 
> But we really need guidance from Chris.

I have not looked at 64bit support in detail for this code. I add the DB_INT to
provide a type that might help but at the time my focus was getting 32bit to
work. Back then I did not know if a single standards based type could fill the
role or a special type was needed and I am no wiser so if those who are working
with 64bit targets say it works for both 32bit and 64bit then I will trust their
judgement and DB_INT can be removed and all spots updated. Note, DB_INT needs to
be removed for the change to make sense.

Gedare, I agree with your observation. I think the dependent code needs to be
checked to make sure further problems are not hidden and we avoid creating new
problems that are not visible.

I would love a back end for the A52 etc but I am realistic that it may not
happen however if a function like hex_decode_uint needs to be updated I suggest
it is.

Joel, if your team at OAR can run a qemu 64 bit arm debug session then I suggest
you turn on the remote protocol trace, inspect the data being exchanged and
check if the decoder will work. The changes seem to look OK but until a test on
32bit ARM hardware like a beaglebone black happens I cannot say.

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

Re: [PATCH] rtems-fdt/rtems-fdt.c: Fix bug in loop termination

[Chris Johns]

On 21/3/21 10:43 pm, Christian Mauderer wrote:
> I pushed the patch on master and 5.

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

Any progress on this issue?
I am currently trying to compile the BBB BSP and the adaptations I did to
the linkcmds.base file are definitely problematic..

Kind Regards
Robin

On Fri, 19 Feb 2021 at 08:08, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 18/02/2021 20:55, Gedare Bloom wrote:
>
> > On Thu, Feb 4, 2021 at 10:58 AM Sebastian Huber
> >   wrote:
> >> On 04/02/2021 18:45, Robin Müller wrote:
> >>
> >>> Could you look into this, based on the existing patch? I don't really
> >>> have the time to look (deeply) into it in the next few weeks,
> >>> and the changes are probably easier  for you to implement. I can offer
> >>> to test it though :-)
> >> Ok, please remind me in a week. I am currently quite busy.
> >>
> > It's been a week.
> I am sorry. What makes things even worse is that I am not in the office
> next week.
> >
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC project: #3850 Modular Network Stacks

[Christian Mauderer]

On 21/03/2021 18:53, Joel Sherrill wrote:



On Sun, Mar 21, 2021, 12:47 PM Vijay Kumar Banerjee > wrote:


Hi Rajiv and Joel,

On Sun, Mar 21, 2021 at 9:06 AM Joel Sherrill mailto:j...@rtems.org>> wrote:
 >
 >
 >
 > On Sun, Mar 21, 2021, 9:20 AM Rajiv Vaidyanathan
mailto:rajiv.vaidyanath...@gmail.com>> wrote:
 >>
 >> Hello RTEMS community,
 >>
 >> I found the ticket: Modular Network Stacks interesting. It would
be great if someone can tell the current status of this ticket and
what contributions can be done as a GSoC project.
 >>
 >> In the prerequisites list given, I have experience in UNIX
socket programming (in C and python), OSI model, basic Wireshark but
I don't have much experience in assembly (I can read assembly but
haven't written assembly code) and device drivers. It would be great
if someone can guide me if I can take up this project.
 >
 >
 > Vijay is the primary mentor for this but I can give you an
outline of what there is to do.
 >
 > RTEMS historically had a 20 to 25 year old port of the FreeBSD
tcpip stack. This was ipv4 only and the source was included in the
main RTEMS repository. It was enabled or disabled via a configure flag.
 >
 > There is now the libbsd repository which is a port of the current
FreeBSD with many features and drivers. It has a focus on what we
call source transparency which means that we do not make changes to
it unless I absolutely necessary and try to preserve the original
source as much as possible. This makes it possible to largely update
the source using scripts. We currently track the FreeBSD 12 release
branch and their development version.
 >
 > With two tcp/ip stacks, it becomes necessary to be able to switch
between them. This project had a first step which was to move the
legacy stack into its own repository. Thanks to Vijay, you can now
build RTEMS without a tcpip stack at all. Then you download and add
on the tcp/ip stack of your choice - legacy or libbsd.
 >
 > But there's a third tcp/ip stack we are interested in. The lwip
stack is targeted at lower memory profiles and is not as full
featured as libbsd. We need an lwip RTEMS repository which includes
lwip, drivers for a variety of BSPs, its own build system, tests,
examples, and any services specific to lwip. Lwip as a project does
not do a good job of providing a central location for device drivers
so the RTEMS lwip repo will be a collection point. providing a
robust set of drivers and keeping track of where they came from and
maintaining Source transparency is key.
 >
 >  This arrangement allows anyone to pick from the set of stacks we
support as long as they deal with the device driver.
 >
 > The GSoC project you would be proposing is the lwip part. We have
a build of it from a user's application to go by for a working
example of the stack. Probably completely ignore the default lwip
build system and uae a waf build system (Python).
 >
The prototype for this repository is ready!
rtems-lwip: https://git.rtems.org/vijay/rtems-lwip.git/


This build follows a similar approach to rtems-libbsd and I have
also added a testcase to it, by modifying the networking01.exe from
the legacy repo.

 > I think this is very doable as GSoC project. Vijay already did
separate the legacy stack into its own repository, we have a test
case BSP, and there is a defined patter to follow.
 >
I think the first step would be identify a target that we can run on
qemu as well as hardware and focus on that target. Porting that
target to LWIP would involve adding a driver to rtems-lwip, along
with a set up to manage the drivers. For managing different drivers,
I propose an ini or yaml configuration file that can be used by waf
scripts to decide which driver to build for a particular bsp.


I think Gedare and I chatted about this so I had some in mind. Zynq and 
MPSoC have lwip drivers from xilinx and both run on qemu.


https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842366/Standalone+LWIP+library 



If it works with the zynq qemu BSP, I think that would be great for that 
kind of stuff. That BSP is always great for debugging (although most 
likely there will be few C-Code-Work in this repo) because you don't 
need extra hardware.




The other top alternative is the PC.


PC is hard for debugging. I never searched but I think you most likely 
don't find many with JTAG connectors ;-)


Beagle could be an alternative for real hardware. I found at least one 
lwip driver for that.




I can't remember what Alan Cudmore was using but it would be good to at 
least 

Re: GSoC project: #3850 Modular Network Stacks

[Joel Sherrill]

On Sun, Mar 21, 2021, 12:47 PM Vijay Kumar Banerjee  wrote:

> Hi Rajiv and Joel,
>
> On Sun, Mar 21, 2021 at 9:06 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Sun, Mar 21, 2021, 9:20 AM Rajiv Vaidyanathan <
> rajiv.vaidyanath...@gmail.com> wrote:
> >>
> >> Hello RTEMS community,
> >>
> >> I found the ticket: Modular Network Stacks interesting. It would be
> great if someone can tell the current status of this ticket and what
> contributions can be done as a GSoC project.
> >>
> >> In the prerequisites list given, I have experience in UNIX socket
> programming (in C and python), OSI model, basic Wireshark but I don't have
> much experience in assembly (I can read assembly but haven't written
> assembly code) and device drivers. It would be great if someone can guide
> me if I can take up this project.
> >
> >
> > Vijay is the primary mentor for this but I can give you an outline of
> what there is to do.
> >
> > RTEMS historically had a 20 to 25 year old port of the FreeBSD tcpip
> stack. This was ipv4 only and the source was included in the main RTEMS
> repository. It was enabled or disabled via a configure flag.
> >
> > There is now the libbsd repository which is a port of the current
> FreeBSD with many features and drivers. It has a focus on what we call
> source transparency which means that we do not make changes to it unless I
> absolutely necessary and try to preserve the original source as much as
> possible. This makes it possible to largely update the source using
> scripts. We currently track the FreeBSD 12 release branch and their
> development version.
> >
> > With two tcp/ip stacks, it becomes necessary to be able to switch
> between them. This project had a first step which was to move the legacy
> stack into its own repository. Thanks to Vijay, you can now build RTEMS
> without a tcpip stack at all. Then you download and add on the tcp/ip stack
> of your choice - legacy or libbsd.
> >
> > But there's a third tcp/ip stack we are interested in. The lwip stack is
> targeted at lower memory profiles and is not as full featured as libbsd. We
> need an lwip RTEMS repository which includes lwip, drivers for a variety of
> BSPs, its own build system, tests, examples, and any services specific to
> lwip. Lwip as a project does not do a good job of providing a central
> location for device drivers so the RTEMS lwip repo will be a collection
> point. providing a robust set of drivers and keeping track of where they
> came from and maintaining Source transparency is key.
> >
> >  This arrangement allows anyone to pick from the set of stacks we
> support as long as they deal with the device driver.
> >
> > The GSoC project you would be proposing is the lwip part. We have a
> build of it from a user's application to go by for a working example of the
> stack. Probably completely ignore the default lwip build system and uae a
> waf build system (Python).
> >
> The prototype for this repository is ready!
> rtems-lwip: https://git.rtems.org/vijay/rtems-lwip.git/
>
> This build follows a similar approach to rtems-libbsd and I have also
> added a testcase to it, by modifying the networking01.exe from the legacy
> repo.
>
> > I think this is very doable as GSoC project. Vijay already did separate
> the legacy stack into its own repository, we have a test case BSP, and
> there is a defined patter to follow.
> >
> I think the first step would be identify a target that we can run on qemu
> as well as hardware and focus on that target. Porting that target to LWIP
> would involve adding a driver to rtems-lwip, along with a set up to manage
> the drivers. For managing different drivers, I propose an ini or yaml
> configuration file that can be used by waf scripts to decide which driver
> to build for a particular bsp.
>

I think Gedare and I chatted about this so I had some in mind. Zynq and
MPSoC have lwip drivers from xilinx and both run on qemu.

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842366/Standalone+LWIP+library

The other top alternative is the PC.

I can't remember what Alan Cudmore was using but it would be good to at
least include it so he can possibly provide feedback on his target.

I would expect STM boards also have l whip drivers from the vendor in their
device driver kit.


> So, roughly the todos for the application phase would be to identify a
> potential target and divide the driver work in two phases as per GSoC
> schedule. This also involves collecting all the old/previously ported
> drivers in one place inside lwip, this will also act as a reference on how
> to proceed with the driver for a new target.
>

Lwip is particularly bad at providing a unified place for drivers. This is
something I never wanted to happen with RTEMS. I think a big value of this
effort will be collecting drivers that can work with RTEMS bsps.



>
> Best regards,
> Vijay
>
> > That's the project in a nutshell. Vijay should speak up and add on.
> >
> >>
> >> Thanks and regards,
> >> Rajiv
> >> 

Re: GSoC project: #3850 Modular Network Stacks

[Vijay Kumar Banerjee]

Hi Rajiv and Joel,

On Sun, Mar 21, 2021 at 9:06 AM Joel Sherrill  wrote:
>
>
>
> On Sun, Mar 21, 2021, 9:20 AM Rajiv Vaidyanathan <
rajiv.vaidyanath...@gmail.com> wrote:
>>
>> Hello RTEMS community,
>>
>> I found the ticket: Modular Network Stacks interesting. It would be
great if someone can tell the current status of this ticket and what
contributions can be done as a GSoC project.
>>
>> In the prerequisites list given, I have experience in UNIX socket
programming (in C and python), OSI model, basic Wireshark but I don't have
much experience in assembly (I can read assembly but haven't written
assembly code) and device drivers. It would be great if someone can guide
me if I can take up this project.
>
>
> Vijay is the primary mentor for this but I can give you an outline of
what there is to do.
>
> RTEMS historically had a 20 to 25 year old port of the FreeBSD tcpip
stack. This was ipv4 only and the source was included in the main RTEMS
repository. It was enabled or disabled via a configure flag.
>
> There is now the libbsd repository which is a port of the current FreeBSD
with many features and drivers. It has a focus on what we call source
transparency which means that we do not make changes to it unless I
absolutely necessary and try to preserve the original source as much as
possible. This makes it possible to largely update the source using
scripts. We currently track the FreeBSD 12 release branch and their
development version.
>
> With two tcp/ip stacks, it becomes necessary to be able to switch between
them. This project had a first step which was to move the legacy stack into
its own repository. Thanks to Vijay, you can now build RTEMS without a
tcpip stack at all. Then you download and add on the tcp/ip stack of your
choice - legacy or libbsd.
>
> But there's a third tcp/ip stack we are interested in. The lwip stack is
targeted at lower memory profiles and is not as full featured as libbsd. We
need an lwip RTEMS repository which includes lwip, drivers for a variety of
BSPs, its own build system, tests, examples, and any services specific to
lwip. Lwip as a project does not do a good job of providing a central
location for device drivers so the RTEMS lwip repo will be a collection
point. providing a robust set of drivers and keeping track of where they
came from and maintaining Source transparency is key.
>
>  This arrangement allows anyone to pick from the set of stacks we support
as long as they deal with the device driver.
>
> The GSoC project you would be proposing is the lwip part. We have a build
of it from a user's application to go by for a working example of the
stack. Probably completely ignore the default lwip build system and uae a
waf build system (Python).
>
The prototype for this repository is ready!
rtems-lwip: https://git.rtems.org/vijay/rtems-lwip.git/

This build follows a similar approach to rtems-libbsd and I have also added
a testcase to it, by modifying the networking01.exe from the legacy repo.

> I think this is very doable as GSoC project. Vijay already did separate
the legacy stack into its own repository, we have a test case BSP, and
there is a defined patter to follow.
>
I think the first step would be identify a target that we can run on qemu
as well as hardware and focus on that target. Porting that target to LWIP
would involve adding a driver to rtems-lwip, along with a set up to manage
the drivers. For managing different drivers, I propose an ini or yaml
configuration file that can be used by waf scripts to decide which driver
to build for a particular bsp.

So, roughly the todos for the application phase would be to identify a
potential target and divide the driver work in two phases as per GSoC
schedule. This also involves collecting all the old/previously ported
drivers in one place inside lwip, this will also act as a reference on how
to proceed with the driver for a new target.


Best regards,
Vijay

> That's the project in a nutshell. Vijay should speak up and add on.
>
>>
>> Thanks and regards,
>> Rajiv
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: #4328: New APIs added to POSIX Standard (2021)

[Joel Sherrill]

On Sun, Mar 21, 2021 at 2:28 AM Matthew Joyce  wrote:

> Gentlemen,
>
> Awesome, thanks!  I see how that works now...I'll give it a thorough
> look tomorrow and will update the spreadsheet accordingly. I'll pipe
> back up when I have a more accurate look of what's currently there.
>

Knowing what doesn't have to be done is the first step. (rtems, newlib, and
libbsd)

I'd be prone to look for things that are easy to add first.

Some may not be implementable on RTEMS due to only supporting a
single process and no virtual memory. If you have doubts on whether it
is possible to support a specific method, speak up and let's try to decide.

Then find upstream places for an implementation where possible. I suspect
all the new "clock" methods will require discussion on an implementation
pattern but those must strictly be added to rtems/cpukit with tests and
documentation. At least I can throw you that much. :)


> Thanks again and have a great Sunday!
>
> Matt
>
> On Fri, Mar 19, 2021 at 8:27 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Fri, Mar 19, 2021 at 1:08 PM Gedare Bloom  wrote:
> >>
> >> On Fri, Mar 19, 2021 at 11:16 AM Matthew Joyce 
> wrote:
> >> >
> >> > Dr. Joel,
> >> >
> >> > Thanks very much...I'll keep working to get a sense of what goes
> >> > where! In the meantime, where can I look to get the ground truth of
> >> > which methods are "in RTEMS" as opposed to those in newlib?
> >> >
> >> There is only one ground truth:
> >> git://git.rtems.org/rtems.git
> >>
> >> And for newlib
> >>
> >> git://sourceware.org/git/newlib-cygwin.git
> >>
> >> That said, searching for the function name symbols in compiled
> >> libraries is a good first step to rule out newlib. Then, you can
> >> 'grep' the RTEMS source code for the function names to see if they
> >> exist there.
> >
> >
> > rtems/cpukit to be specitic. It won't be implemented anywhere else.
> >
> > And clearly we both have forgotten that networking APIs are in the
> > rtems-libbsd repository.
> >
> > https://git.rtems.org/rtems-libbsd/
> >
> > I suspect ppoll() might already be in there. Or at least supported by
> > FreeBSD.
> >
> > You should clone everything and grep the sources. newlib already has
> > qsort_r. This is the nm I used:
> >
> > $ ~/rtems-work/tools/6/bin/sparc-rtems6-nm
> ~/rtems-work/tools/6/sparc-rtems6/lib/libc.a | grep qsort_r
> > lib_a-bsd_qsort_r.o:
> >  T __bsd_qsort_r
> > lib_a-qsort_r.o:
> >  T qsort_r
> >
> > Notice the last line has "T qsort_r" which says it is defined.
> >
> > grep -r in the newlib source shows it is in ./libc/search/qsort_r.c
> >
> > dladdr() looks to be prototyped in RTEMS but hidden behind an ifdef like
> it
> > wasn't ported from NetBSD so that looks possible. It is in rtems.
> >
> > Those two examples should help you figure out why you missed
> > finding some things that were implemented.
> >
> > I need to figure out what this next POSIX version is to be called
> > so I can update the tracking spreadsheet that generates the RTEMS
> > POSIX Compliance Guide, :)
> >
> > --joel
> >>
> >>
> >> > Thanks again!
> >> >
> >> > Matt
> >> >
> >> > On Fri, Mar 19, 2021 at 1:58 PM Joel Sherrill  wrote:
> >> > >
> >> > > Keep devel@ on the list. :)
> >> > >
> >> > > On Fri, Mar 19, 2021 at 7:51 AM Matthew Joyce <
> mfjoyce2...@gmail.com> wrote:
> >> > >>
> >> > >> Sir,
> >> > >>
> >> > >> Thank you for the link! I see that you're right, those last four
> are
> >> > >> in newlib, plus memmem(). I updated those in the Google Sheet.
> >> > >>
> >> > >> Now I see the newlib part, but where are you referring to
> specifically
> >> > >> when you say RTEMS, as in "POSIX support comes from a mix of RTEMS
> and
> >> > >> newlib"?
> >> > >
> >> > >
> >> > > POSIX is a HUGE HUGE standard and references other standards. One
> >> > > it references and pulls in is the C99 Standard C Library which is
> libc and
> >> > > libm. RTEMS mostly does not implement this functionality and relies
> on
> >> > > another open source project for those APIs. Newlib is an open source
> >> > > C Library used by RTEMS, Cygwin, and most embedded systems GNU tools
> >> > > chains.
> >> > >
> >> > > Most of the POSIX header files with RTEMS are actually in Newlib
> even
> >> > > if they originated with RTEMS. Many are shared with Cygwin.
> >> > >
> >> > > So methods like the string, memory, and *printf come from Newlib
> since they
> >> > > are in C99. We provide POSIX like threading, signals, core file
> access, and
> >> > > much more.
> >> > >
> >> > > It's a complementary relationship but it takes a bit to figure out
> when
> >> > > something should be in one or the other. The line gets blurred at
> times.
> >> > >
> >> > > Say you added a new CPU architecture implementation of a math
> >> > > method (like Eshan did last year), then it goes in newlib. But he
> also
> >> > > added some POSIX methods which go in RTEMS. In either case,
> >> > > we like tests for them in RTEMS to show they work in our
> environment.
> >> > >
> >> > > 

Re: GSOC project: #4334 Replace Mongoose with Civetweb

[Joel Sherrill]

On Sun, Mar 21, 2021, 4:45 AM Christian Mauderer  wrote:

> Hello Ayushman,
>
> On 21/03/2021 04:15, Ayushman Mishra wrote:
> > Ayushman
> > Hello everyone , I am very much interested in taking
> > https://devel.rtems.org/ticket/4334
> > as a GSOC 2021 project. I know some basic networking concepts and would
> like to
> > learn more about it and how its applied to OS like RTEMS , regarding
> > this I have some questions.
>
> Note that the ticket will be more about integrating civetweb into a
> RTEMS Source Builder (RSB) recipe and finding a way to make it
> configurable there. Alternative could be some kind of stand alone repo
> like for littlevgl.
>

Making the civitweb configure options available to RTEMS user is a key
point.

It may make sense to do a repo with waf build system and config.ini that
maps to their settings.


> civetweb builds on RTEMS nearly out of the box. So don't expect too much
> C-Code.
>

I set it up recently on Linux for embedding in their application. As you
turned on options, it had more dependencies. This would have to be managed
with RTEMS.


> I'm not yet sure how much work will be on that ticket. If it is too few
> for a whole GSoC, you might want to think about reviving the discussion
> about some useful civetweb parameters (for an embedded system) here:
>
>  https://github.com/civetweb/civetweb/pull/297


+1

How to present the options to the user and manage their dependencies would
be a key part of this.

>
>
>
> >
> > 1. After building a simple hello world application how and where should
> i write
> > configurations of
> >
> https://docs.rtems.org/branches/master/networking/using_networking_rtems_app.html
> > OR
> https://docs.rtems.org/branches/master/user/migration/v4_11-to-v5.html#networking
> > to start using networking stack in RTEMS .
>
> The documentation is currently mostly for the legacy stack. Please
> ignore most of that. You should focus on a BSP that uses libbsd. The
> legacy stack and it's documentation will be removed from the main repos
> soon.
>
> > Also I think a simple shell has to be spawned to use networking modules
> in RTEMS
> > and for getting it this
> >
> https://docs.rtems.org/branches/master/shell/configuration_and_init.html#attached-to-a-serial-port
> > I think could be a simple method and for doing so ( like executing
> > rtems_shell_init with parameters )
> > do i have to run the specific test in testsuite or re-run the application
>
> There is a "mghttpd01" test in rtems-libbsd which is used for the
> current fixed version of mongoose that is integrated in RTEMS. I would
> suggest to use that as a starting point.
>
> >
> > 2. Is there any specific device or bsp needed for running networking
> > or shell configurations
> > with file-system in RTEMS
>
> Basically you can use every BSP that has network support. A good
> simulation BSP where you don't need any hardware is xilinx_zynq_a9_qemu:
>
>
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-with-xilinx-zynq-a9-qemu
>
> Best Regards
>
> Christian
>
> > I would be very thankful if someone can please clarify my doubts and
> > guide me further
> > with this project as I am getting lost and don't know how to proceed
> > after building a simple application.
> > Thank-you
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC project: #3850 Modular Network Stacks

[Joel Sherrill]

On Sun, Mar 21, 2021, 9:20 AM Rajiv Vaidyanathan <
rajiv.vaidyanath...@gmail.com> wrote:

> Hello RTEMS community,
>
> I found the ticket: Modular Network Stacks interesting. It would be great
> if someone can tell the current status of this ticket and what
> contributions can be done as a GSoC project.
>
> In the prerequisites list given, I have experience in UNIX socket
> programming (in C and python), OSI model, basic Wireshark but I don't have
> much experience in assembly (I can read assembly but haven't written
> assembly code) and device drivers. It would be great if someone can guide
> me if I can take up this project.
>

Vijay is the primary mentor for this but I can give you an outline of what
there is to do.

RTEMS historically had a 20 to 25 year old port of the FreeBSD tcpip stack.
This was ipv4 only and the source was included in the main RTEMS
repository. It was enabled or disabled via a configure flag.

There is now the libbsd repository which is a port of the current FreeBSD
with many features and drivers. It has a focus on what we call source
transparency which means that we do not make changes to it unless I
absolutely necessary and try to preserve the original source as much as
possible. This makes it possible to largely update the source using
scripts. We currently track the FreeBSD 12 release branch and their
development version.

With two tcp/ip stacks, it becomes necessary to be able to switch between
them. This project had a first step which was to move the legacy stack into
its own repository. Thanks to Vijay, you can now build RTEMS without a
tcpip stack at all. Then you download and add on the tcp/ip stack of your
choice - legacy or libbsd.

But there's a third tcp/ip stack we are interested in. The lwip stack is
targeted at lower memory profiles and is not as full featured as libbsd. We
need an lwip RTEMS repository which includes lwip, drivers for a variety of
BSPs, its own build system, tests, examples, and any services specific to
lwip. Lwip as a project does not do a good job of providing a central
location for device drivers so the RTEMS lwip repo will be a collection
point. providing a robust set of drivers and keeping track of where they
came from and maintaining Source transparency is key.

 This arrangement allows anyone to pick from the set of stacks we support
as long as they deal with the device driver.

The GSoC project you would be proposing is the lwip part. We have a build
of it from a user's application to go by for a working example of the
stack. Probably completely ignore the default lwip build system and uae a
waf build system (Python).

I think this is very doable as GSoC project. Vijay already did separate the
legacy stack into its own repository, we have a test case BSP, and there is
a defined patter to follow.

That's the project in a nutshell. Vijay should speak up and add on.


> Thanks and regards,
> Rajiv
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC project: #3850 Modular Network Stacks

[Rajiv Vaidyanathan]

Hello RTEMS community,

I found the ticket: Modular Network Stacks interesting. It would be great
if someone can tell the current status of this ticket and what
contributions can be done as a GSoC project.

In the prerequisites list given, I have experience in UNIX socket
programming (in C and python), OSI model, basic Wireshark but I don't have
much experience in assembly (I can read assembly but haven't written
assembly code) and device drivers. It would be great if someone can guide
me if I can take up this project.

Thanks and regards,
Rajiv
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] bsp/beagle: Ported Beagle pinmux driver to RTEMS

[Christian Mauderer]

Hello Niteesh,

thanks for the patches. I tested them (together with the libbsd one) 
with BBB and a littlevgl demo and they work fine. I pushed them.


Best regards

Christian

PS: Sorry for the double mail. I used the wrong sender for the list (again).

On 13/03/2021 12:19, Niteesh G. S. wrote:

Hello,

I tested this patch by removing the pinmux initialization code from the 
Beagle I2C
driver and letting this driver do the initialization. I then used the 
I2C driver to read
the EEPROM in the pocket beagle using the I2C driver. The initialization 
of the

pinmux settings was also confirmed using JTAG.

To confirm that the driver also works in libBSD I used the media01 
example to
write a test file to the SD card. Though I couldn't write to it due to 
some pre-existing
issue which I also faced during GSoC I was able to get the SD card 
details like the size

and make which gives some hope that the driver works in libBSD too.

I kindly request people owning beagle hardware to test the driver.

I also apologies for the long inactivity, I was consumed with other 
activities which left

me no free time to work on this post-GSoC.

Thanks,
Niteesh.

On Sat, Mar 13, 2021 at 4:32 PM G S Niteesh Babu > wrote:


The following files have been ported
1) ti_pinmux.c
2) ti_pinmux.h
3) am335x_scm_padconf.c
4) am335x_scm_padconf.h

Update #3784
---
  bsps/arm/beagle/start/bspstart.c              |  31 +
  bsps/include/arm/ti/ti_pinmux.h               |   9 +-
  .../sys/arm/ti/am335x/am335x_scm_padconf.c    |   4 +
  bsps/shared/freebsd/sys/arm/ti/ti_pinmux.c    | 115 +-
  spec/build/bsps/obj.yml                       |   6 +
  5 files changed, 163 insertions(+), 2 deletions(-)

diff --git a/bsps/arm/beagle/start/bspstart.c
b/bsps/arm/beagle/start/bspstart.c
index 0a6f1b4a64..a0736294c9 100644
--- a/bsps/arm/beagle/start/bspstart.c
+++ b/bsps/arm/beagle/start/bspstart.c
@@ -20,6 +20,8 @@
  #include 
  #include 
  #include "bsp-soc-detect.h"
+#include 
+#include 

  #include "bspdebug.h"

@@ -55,6 +57,29 @@ uint32_t bsp_fdt_map_intr(const uint32_t *intr,
size_t icells)
    return intr[0];
  }

+static void traverse_fdt_nodes( phandle_t node )
+{
+
+  for (node = rtems_ofw_child(node); node != 0; node =
rtems_ofw_peer(node)) {
+    traverse_fdt_nodes(node);
+
+    if (!rtems_ofw_node_status(node))
+      continue;
+
+    /*
+     * Put all driver initialization functions here
+     */
+    beagle_pinmux_init(node);
+  }
+}
+
+static void bbb_drivers_initialize(void)
+{
+  phandle_t node = rtems_ofw_peer(0);
+
+  traverse_fdt_nodes(node);
+}
+
  static void bbb_i2c_0_initialize(void)
  {
    int err;
@@ -73,3 +98,9 @@ RTEMS_SYSINIT_ITEM(
    RTEMS_SYSINIT_LAST,
    RTEMS_SYSINIT_ORDER_LAST_BUT_5
  );
+
+RTEMS_SYSINIT_ITEM(
+       bbb_drivers_initialize,
+       RTEMS_SYSINIT_BSP_PRE_DRIVERS,
+       RTEMS_SYSINIT_ORDER_LAST
+);
diff --git a/bsps/include/arm/ti/ti_pinmux.h
b/bsps/include/arm/ti/ti_pinmux.h
index 52409df61d..208e327c2b 100644
--- a/bsps/include/arm/ti/ti_pinmux.h
+++ b/bsps/include/arm/ti/ti_pinmux.h
@@ -42,6 +42,9 @@
   */
  #ifndef _TI_PINMUX_H_
  #define _TI_PINMUX_H_
+#ifdef __rtems__
+#include 
+#endif /* __rtems__ */

  struct ti_pinmux_padconf {
         uint16_t    reg_off;
@@ -63,12 +66,16 @@ struct ti_pinmux_device {
         const struct ti_pinmux_padconf  *padconf;
  };

+#ifndef __rtems__
  struct ti_pinmux_softc {
         device_t                sc_dev;
         struct resource *       sc_res[4];
         bus_space_tag_t         sc_bst;
         bus_space_handle_t      sc_bsh;
  };
+#else /* __rtems__ */
+void beagle_pinmux_init(phandle_t node);
+#endif /* __rtems__ */

  int ti_pinmux_padconf_set(const char *padname, const char *muxmode,
      unsigned int state);
@@ -77,4 +84,4 @@ int ti_pinmux_padconf_get(const char *padname,
const char **muxmode,
  int ti_pinmux_padconf_set_gpiomode(uint32_t gpio, unsigned int state);
  int ti_pinmux_padconf_get_gpiomode(uint32_t gpio, unsigned int
*state);

-#endif /* _TI_SCM_H_ */
\ No newline at end of file
+#endif /* _TI_SCM_H_ */
diff --git
a/bsps/shared/freebsd/sys/arm/ti/am335x/am335x_scm_padconf.c
b/bsps/shared/freebsd/sys/arm/ti/am335x/am335x_scm_padconf.c
index 44a36a754b..e5cb1801e1 100644
--- a/bsps/shared/freebsd/sys/arm/ti/am335x/am335x_scm_padconf.c
+++ b/bsps/shared/freebsd/sys/arm/ti/am335x/am335x_scm_padconf.c
@@ -27,9 +27,12 @@
   */

  #include 
+#ifndef __rtems__
  __FBSDID("$FreeBSD$");
+#endif /* __rtems__ */

  #include 

Re: [PATCH] rtems-fdt/rtems-fdt.c: Fix bug in loop termination

[Christian Mauderer]

Hello Gedare and Niteesh,

I pushed the patch on master and 5.

Niteesh: Thanks for finding and fixing that bug.

Best regards

Christian

On 21/03/2021 08:04, Niteesh G. S. wrote:



On Sat, Mar 20, 2021 at 11:39 AM Gedare Bloom > wrote:


This looks good to me. Is the bug also on 5? If so, a ticket should be
opened and a patch filed for 5.2.

This bug is also present in 5.
I have filed a ticket for this https://devel.rtems.org/ticket/4350 



If someone cares to push this please go ahead. I wouldn't get to it
until next week sometime. Niteesh, ping it on Tuesday if no one has
pushed.

OK


On Wed, Mar 17, 2021 at 8:51 PM G S Niteesh Babu
mailto:niteesh...@gmail.com>> wrote:
 >
 > The while loop, loops infinitely in case of raw FDT data.
 > The loop condition (size) is not modified during iterations.
 > ---
 >  cpukit/libmisc/rtems-fdt/rtems-fdt.c | 2 +-
 >  1 file changed, 1 insertion(+), 1 deletion(-)
 >
 > diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
 > index 0ea365314f..7747ba9bf8 100644
 > --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
 > +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
 > @@ -580,7 +580,7 @@ rtems_fdt_load (const char* filename,
rtems_fdt_handle* handle)
 >          close (bf);
 >          return -RTEMS_FDT_ERR_READ_FAIL;
 >        }
 > -      r -= size;
 > +      size -= r;
 >        buf += r;
 >      }
 >    }
 > --
 > 2.17.1
 >
 > ___
 > devel mailing list
 > devel@rtems.org 
 > http://lists.rtems.org/mailman/listinfo/devel



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


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

Re: GSOC project: #4334 Replace Mongoose with Civetweb

[Christian Mauderer]

Hello Ayushman,

On 21/03/2021 04:15, Ayushman Mishra wrote:

Ayushman
Hello everyone , I am very much interested in taking
https://devel.rtems.org/ticket/4334
as a GSOC 2021 project. I know some basic networking concepts and would like to
learn more about it and how its applied to OS like RTEMS , regarding
this I have some questions.


Note that the ticket will be more about integrating civetweb into a 
RTEMS Source Builder (RSB) recipe and finding a way to make it 
configurable there. Alternative could be some kind of stand alone repo 
like for littlevgl.


civetweb builds on RTEMS nearly out of the box. So don't expect too much 
C-Code.


I'm not yet sure how much work will be on that ticket. If it is too few 
for a whole GSoC, you might want to think about reviving the discussion 
about some useful civetweb parameters (for an embedded system) here:


https://github.com/civetweb/civetweb/pull/297




1. After building a simple hello world application how and where should i write
configurations of
https://docs.rtems.org/branches/master/networking/using_networking_rtems_app.html
OR  
https://docs.rtems.org/branches/master/user/migration/v4_11-to-v5.html#networking
to start using networking stack in RTEMS .


The documentation is currently mostly for the legacy stack. Please 
ignore most of that. You should focus on a BSP that uses libbsd. The 
legacy stack and it's documentation will be removed from the main repos 
soon.



Also I think a simple shell has to be spawned to use networking modules in RTEMS
and for getting it this
https://docs.rtems.org/branches/master/shell/configuration_and_init.html#attached-to-a-serial-port
I think could be a simple method and for doing so ( like executing
rtems_shell_init with parameters )
do i have to run the specific test in testsuite or re-run the application


There is a "mghttpd01" test in rtems-libbsd which is used for the 
current fixed version of mongoose that is integrated in RTEMS. I would 
suggest to use that as a starting point.




2. Is there any specific device or bsp needed for running networking
or shell configurations
with file-system in RTEMS


Basically you can use every BSP that has network support. A good 
simulation BSP where you don't need any hardware is xilinx_zynq_a9_qemu:


https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-with-xilinx-zynq-a9-qemu

Best Regards

Christian


I would be very thankful if someone can please clarify my doubts and
guide me further
with this project as I am getting lost and don't know how to proceed
after building a simple application.
Thank-you
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


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

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Gentlemen,

Awesome, thanks!  I see how that works now...I'll give it a thorough
look tomorrow and will update the spreadsheet accordingly. I'll pipe
back up when I have a more accurate look of what's currently there.
Thanks again and have a great Sunday!

Matt

On Fri, Mar 19, 2021 at 8:27 PM Joel Sherrill  wrote:
>
>
>
> On Fri, Mar 19, 2021 at 1:08 PM Gedare Bloom  wrote:
>>
>> On Fri, Mar 19, 2021 at 11:16 AM Matthew Joyce  wrote:
>> >
>> > Dr. Joel,
>> >
>> > Thanks very much...I'll keep working to get a sense of what goes
>> > where! In the meantime, where can I look to get the ground truth of
>> > which methods are "in RTEMS" as opposed to those in newlib?
>> >
>> There is only one ground truth:
>> git://git.rtems.org/rtems.git
>>
>> And for newlib
>>
>> git://sourceware.org/git/newlib-cygwin.git
>>
>> That said, searching for the function name symbols in compiled
>> libraries is a good first step to rule out newlib. Then, you can
>> 'grep' the RTEMS source code for the function names to see if they
>> exist there.
>
>
> rtems/cpukit to be specitic. It won't be implemented anywhere else.
>
> And clearly we both have forgotten that networking APIs are in the
> rtems-libbsd repository.
>
> https://git.rtems.org/rtems-libbsd/
>
> I suspect ppoll() might already be in there. Or at least supported by
> FreeBSD.
>
> You should clone everything and grep the sources. newlib already has
> qsort_r. This is the nm I used:
>
> $ ~/rtems-work/tools/6/bin/sparc-rtems6-nm 
> ~/rtems-work/tools/6/sparc-rtems6/lib/libc.a | grep qsort_r
> lib_a-bsd_qsort_r.o:
>  T __bsd_qsort_r
> lib_a-qsort_r.o:
>  T qsort_r
>
> Notice the last line has "T qsort_r" which says it is defined.
>
> grep -r in the newlib source shows it is in ./libc/search/qsort_r.c
>
> dladdr() looks to be prototyped in RTEMS but hidden behind an ifdef like it
> wasn't ported from NetBSD so that looks possible. It is in rtems.
>
> Those two examples should help you figure out why you missed
> finding some things that were implemented.
>
> I need to figure out what this next POSIX version is to be called
> so I can update the tracking spreadsheet that generates the RTEMS
> POSIX Compliance Guide, :)
>
> --joel
>>
>>
>> > Thanks again!
>> >
>> > Matt
>> >
>> > On Fri, Mar 19, 2021 at 1:58 PM Joel Sherrill  wrote:
>> > >
>> > > Keep devel@ on the list. :)
>> > >
>> > > On Fri, Mar 19, 2021 at 7:51 AM Matthew Joyce  
>> > > wrote:
>> > >>
>> > >> Sir,
>> > >>
>> > >> Thank you for the link! I see that you're right, those last four are
>> > >> in newlib, plus memmem(). I updated those in the Google Sheet.
>> > >>
>> > >> Now I see the newlib part, but where are you referring to specifically
>> > >> when you say RTEMS, as in "POSIX support comes from a mix of RTEMS and
>> > >> newlib"?
>> > >
>> > >
>> > > POSIX is a HUGE HUGE standard and references other standards. One
>> > > it references and pulls in is the C99 Standard C Library which is libc 
>> > > and
>> > > libm. RTEMS mostly does not implement this functionality and relies on
>> > > another open source project for those APIs. Newlib is an open source
>> > > C Library used by RTEMS, Cygwin, and most embedded systems GNU tools
>> > > chains.
>> > >
>> > > Most of the POSIX header files with RTEMS are actually in Newlib even
>> > > if they originated with RTEMS. Many are shared with Cygwin.
>> > >
>> > > So methods like the string, memory, and *printf come from Newlib since 
>> > > they
>> > > are in C99. We provide POSIX like threading, signals, core file access, 
>> > > and
>> > > much more.
>> > >
>> > > It's a complementary relationship but it takes a bit to figure out when
>> > > something should be in one or the other. The line gets blurred at times.
>> > >
>> > > Say you added a new CPU architecture implementation of a math
>> > > method (like Eshan did last year), then it goes in newlib. But he also
>> > > added some POSIX methods which go in RTEMS. In either case,
>> > > we like tests for them in RTEMS to show they work in our environment.
>> > >
>> > > --joel
>> > >
>> > >
>> > >
>> > >>
>> > >> Thanks again!
>> > >>
>> > >> Matt
>> > >>
>> > >> On Fri, Mar 19, 2021 at 1:13 PM Joel Sherrill  wrote:
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Fri, Mar 19, 2021, 6:40 AM Joel Sherrill  wrote:
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> On Fri, Mar 19, 2021, 5:48 AM Matthew Joyce  
>> > >> >> wrote:
>> > >> >>>
>> > >> >>> https://docs.google.com/spreadsheets/d/1reCNOIZC5JTwQENgl-hvG8THfQqNtlUDVy_07PYodic/edit?usp=sharing
>> > >> >>>
>> > >> >>> Hello,
>> > >> >>>
>> > >> >>> As suggested by Dr. Sherril, I've taken an initial look through this
>> > >> >>> document https://www.opengroup.org/austin/docs/austin_1110.pdf and
>> > >> >>> added the new methods  to a Googe Sheet, linked above.
>> > >> >>>
>> > >> >>> None of them appear to be in the RTEMS POSIX API Users Guide, but
>> > >> >>> maybe that's not the right place to look. I'll stand by for your
>> > >> >>> feedback regarding 

Re: [PATCH] rtems-fdt/rtems-fdt.c: Fix bug in loop termination

[Niteesh G. S.]

On Sat, Mar 20, 2021 at 11:39 AM Gedare Bloom  wrote:

> This looks good to me. Is the bug also on 5? If so, a ticket should be
> opened and a patch filed for 5.2.
>
This bug is also present in 5.
I have filed a ticket for this https://devel.rtems.org/ticket/4350

> If someone cares to push this please go ahead. I wouldn't get to it
> until next week sometime. Niteesh, ping it on Tuesday if no one has
> pushed.
>
OK

>
> On Wed, Mar 17, 2021 at 8:51 PM G S Niteesh Babu 
> wrote:
> >
> > The while loop, loops infinitely in case of raw FDT data.
> > The loop condition (size) is not modified during iterations.
> > ---
> >  cpukit/libmisc/rtems-fdt/rtems-fdt.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> > index 0ea365314f..7747ba9bf8 100644
> > --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> > +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> > @@ -580,7 +580,7 @@ rtems_fdt_load (const char* filename,
> rtems_fdt_handle* handle)
> >  close (bf);
> >  return -RTEMS_FDT_ERR_READ_FAIL;
> >}
> > -  r -= size;
> > +  size -= r;
> >buf += r;
> >  }
> >}
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel