Re: Draft for moving network headers from RTEMS to newlib

[Sebastian Huber]

On 26/04/16 07:51, Chris Johns wrote:

On 26/04/2016 01:06, Christian Mauderer wrote:

currently we try to remove the network specific POSIX headers from
RTEMS. Instead, we add current headers from FreeBSD to newlib. This will
simplify the build process of some libraries that depend on the network
(like LibreSSL).


What does this work flow offer over building and installing an RTEMS 
kernel for a BSP and adding that path to the packages include paths?


You don't build per BSP in this scenario. You build per multilib and 
have only one set of header files installed. You are able to use the 
network header files during GCC build, which makes it easier to build 
the run-time libraries of Ada and Go.




How do you get the flags for the compiler to build the package?


See attached script which builds for example libpng for all multilibs. 
You don't need BSPs installed to do this. The libpng is just an add-on 
to the tool chain.




How are any tests present in the package built and linked?


Tests are executables, so they need a BSP.



Do we risk limited the functionality of a package by restricting the 
headers exposed to only standards based headers? There are headers 
which some packages use that will not be present.


In case a common header file is missing for a particular package, then 
we can add this file to Newlib.





Further it will be another step into the direction of
extracting the old RTEMS network stack and build it as an independent
package.


Is this just a specialised version of the generic vertical integration 
problem being discussed in the civetweb thread?


I am not against standards based headers like the ones being discussed 
here being move to newlib however I currently do not see what the 
advantage is and how value is being adding over a specific build order 
of packages.


Building libraries against a particular BSP using actually BSP 
independent header files is not really a great overall setup.




I still see all the normal issues of CFLAGS, LDFLAGS, 3rd party 
package dependence still being present once this work is completed.


For libraries, the LDFLAGS are irrelevant. One advantage is that the 
built-in search paths are sufficient if you build against a multilib 
(except the machine flags), see attached script.


--
Sebastian Huber, embedded brains GmbH

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

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



install.sh
Description: application/shellscript
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Draft for moving network headers from RTEMS to newlib

[Chris Johns]

On 26/04/2016 17:31, Sebastian Huber wrote:

On 26/04/16 07:51, Chris Johns wrote:

On 26/04/2016 01:06, Christian Mauderer wrote:

currently we try to remove the network specific POSIX headers from
RTEMS. Instead, we add current headers from FreeBSD to newlib. This will
simplify the build process of some libraries that depend on the network
(like LibreSSL).


What does this work flow offer over building and installing an RTEMS
kernel for a BSP and adding that path to the packages include paths?


You don't build per BSP in this scenario. You build per multilib and
have only one set of header files installed.


Hmm multilib, this is what I thought was happening. I see this exploding 
the libraries if packages are built this way. Do we manage this or not 
bother and just accept all variants have to be built?



You are able to use the
network header files during GCC build, which makes it easier to build
the run-time libraries of Ada and Go.


Nice. Maybe limiting what is added to just building languages would be a 
nice first starting point.






How do you get the flags for the compiler to build the package?


See attached script which builds for example libpng for all multilibs.


Multilibs has not had a very successful history with RTEMS (outside of 
gcc). They are not very user friendly and are a source of questions and 
issues.


I would like to see something more than a script posted before I get 
excited and accepting of this path. I would like to understand the work 
flow for the project, the developers and the users?



You don't need BSPs installed to do this. The libpng is just an add-on
to the tool chain.


Sure, I understand this and it is nice. I hope users do not forget to 
build the BSP. ;)






How are any tests present in the package built and linked?


Tests are executables, so they need a BSP.



Yes, so how do these packages get tested?



Do we risk limited the functionality of a package by restricting the
headers exposed to only standards based headers? There are headers
which some packages use that will not be present.


In case a common header file is missing for a particular package, then
we can add this file to Newlib.



If a package changes or something happens we would need a new version of 
tools. I am concerned about the management of the detail here and 
finding a suitable set of headers for all packages across all 
architecture may become complicated if there are incompatibilities 
between architectures and/or packages. With standards based headers we 
have the standard to fall back on and we can get the package fixed. When 
we move away from standards based headers we open up a range potential 
issue. Adding the headers is easy, removing would be hard if not 
impossible. Once we head down this path will be difficult to turn back.


It is a massive task to get the tools to build for supported 
architectures _now_ and I hope this path does not increase the work load 
here.


Do you have limits or boundaries for suitable headers? Who administers 
these boundaries?


What is the procedure for a user to add a header?

If a header is missing does this means the user cannot build a package? 
In other words can we mix how we currently build packages with this way 
of building packages?





Further it will be another step into the direction of
extracting the old RTEMS network stack and build it as an independent
package.


Is this just a specialised version of the generic vertical integration
problem being discussed in the civetweb thread?

I am not against standards based headers like the ones being discussed
here being move to newlib however I currently do not see what the
advantage is and how value is being adding over a specific build order
of packages.


Building libraries against a particular BSP using actually BSP
independent header files is not really a great overall setup.


Correct each BSP is independent and that gives me the ability to vary 
and change things in RTEMS without needing to repeat tools builds or 
create separate sandboxes at the tools level. The whole point of the 
cpukit was to multilib build the generic code and avoid the duplication 
in the BSPs however in the end it became clear a single specific BSP is 
all most users need and overhead of that specific build and install even 
with per BSP headers is faster and simpler than the whole multilib path.


Having a single tree of headers is fine if they are stable and not 
changing. I do not use a single prefix and prefer separate prefixes so I 
can mix and match and play. Having more and more header become part of 
the tools removes an important part of this process.


It comes down to the type of header and how often they change.





I still see all the normal issues of CFLAGS, LDFLAGS, 3rd party
package dependence still being present once this work is completed.


For libraries, the LDFLAGS are irrelevant.


What about testing? This needs to be resolved.


One advantage is that the
built-in search pa

Re: Draft for moving network headers from RTEMS to newlib

[Sebastian Huber]

On 26/04/16 10:27, Chris Johns wrote:

On 26/04/2016 17:31, Sebastian Huber wrote:

On 26/04/16 07:51, Chris Johns wrote:

On 26/04/2016 01:06, Christian Mauderer wrote:

currently we try to remove the network specific POSIX headers from
RTEMS. Instead, we add current headers from FreeBSD to newlib. This 
will
simplify the build process of some libraries that depend on the 
network

(like LibreSSL).


What does this work flow offer over building and installing an RTEMS
kernel for a BSP and adding that path to the packages include paths?


You don't build per BSP in this scenario. You build per multilib and
have only one set of header files installed.


Hmm multilib, this is what I thought was happening. I see this 
exploding the libraries if packages are built this way. Do we manage 
this or not bother and just accept all variants have to be built?


The multilibs are there for a purpose. In case a particular architecture 
has superfluous multilibs, then we should remove them. I see an 
explosion of libraries if we build them for each BSP. We have count of 
BSPs > count of multilibs, otherwise the GCC configuration is broken.





You are able to use the
network header files during GCC build, which makes it easier to build
the run-time libraries of Ada and Go.


Nice. Maybe limiting what is added to just building languages would be 
a nice first starting point.






How do you get the flags for the compiler to build the package?


See attached script which builds for example libpng for all multilibs.


Multilibs has not had a very successful history with RTEMS (outside of 
gcc). They are not very user friendly and are a source of questions 
and issues.


I think multilibs are great for libraries which don't depend on BSP 
specifics. What is the benefit of per BSP libpng for example?




I would like to see something more than a script posted before I get 
excited and accepting of this path. I would like to understand the 
work flow for the project, the developers and the users?



You don't need BSPs installed to do this. The libpng is just an add-on
to the tool chain.


Sure, I understand this and it is nice. I hope users do not forget to 
build the BSP. ;)


The work flow is build the tool chain, build all support libraries you 
are interested in, then build the actual BSPs.








How are any tests present in the package built and linked?


Tests are executables, so they need a BSP.



Yes, so how do these packages get tested?


How are packages tested currently?

You can only test using a particular BSP.





Do we risk limited the functionality of a package by restricting the
headers exposed to only standards based headers? There are headers
which some packages use that will not be present.


In case a common header file is missing for a particular package, then
we can add this file to Newlib.



If a package changes or something happens we would need a new version 
of tools. 


Yes, but this area is not really volatile. Its not that we have a new 
POSIX standard every two months. The old network stack uses about 20 
year old header files.


I am concerned about the management of the detail here and finding a 
suitable set of headers for all packages across all architecture may 
become complicated if there are incompatibilities between 
architectures and/or packages. With standards based headers we have 
the standard to fall back on and we can get the package fixed. When we 
move away from standards based headers we open up a range potential 
issue. Adding the headers is easy, removing would be hard if not 
impossible. Once we head down this path will be difficult to turn back.


The place of the header file makes no difference here. For the user its 
the same if you remove the file from Newlib or RTEMS.




It is a massive task to get the tools to build for supported 
architectures _now_ and I hope this path does not increase the work 
load here.


If we add Ada and Go to the standard languages, then it could get more 
difficult.




Do you have limits or boundaries for suitable headers? Who administers 
these boundaries?


What is the procedure for a user to add a header?


Like everything else in RTEMS this will be user driven. Someone is not 
satisfied with the current situation and will work out a fix.




If a header is missing does this means the user cannot build a 
package? In other words can we mix how we currently build packages 
with this way of building packages?


You can still build against a BSP which presents the full set of header 
files.







Further it will be another step into the direction of
extracting the old RTEMS network stack and build it as an independent
package.


Is this just a specialised version of the generic vertical integration
problem being discussed in the civetweb thread?

I am not against standards based headers like the ones being discussed
here being move to newlib however I currently do not see what the
advantage is and how value is being adding over a

Re: [PATCH 00/13] Replace mongoose with civetweb.

[Christian Mauderer]

Am 26.04.2016 um 04:51 schrieb Chris Johns:
> On 26/04/2016 07:22, Joel Sherrill wrote:
>> Agreed 100%!
>>
>> NTP has an RSB recipe and there are others for various libraries which
>> should be good examples. Shouldn't take long to do the recipe. Just ask
>> questions rather than getting stuck.
>>
>> On Apr 25, 2016 7:03 PM, "Gedare Bloom" > > wrote:
>>
>> On Mon, Apr 25, 2016 at 11:25 AM, Joel Sherrill > > wrote:
>>  >
>>  >
>>  > On Mon, Apr 25, 2016 at 4:22 AM, Christian Mauderer
>>  > > > wrote:
>>  >>
>>  >> Essentially I agree that it would be nice to build civetweb as an
>>  >> external library especially with the different network stacks in
>> mind.
>>  >> But there are some points that keep me from doing it:
>>  >>
>>  >> 1. I have really no Idea what would be necessary to build it
>> as an
>>  >> upstream project using RSB. If that are only something like
>> three simple
>>  >> steps, it should be possible to squeeze it in the little time
>> budget
>>  >> that is left for the project. If I first have to analyze and
>> change a
>>  >> lot of RSB, it would be challenging.
>>  >>
>>  > FWIW I think this can be a secondary goal. Switching over to
>> the real
>>  > upstream project with proper licensing is important.
> 
> I see both as equally important and once the switch is made we have an
> on going liability in the project to keep the packaging maintained so
> considering it a bit more I suppose the long term issue is actually more
> important to me.

There is still some work left before we can use the upstream project. I
more or less took over most of the patches that we applied to mongoose.
Most of them should just need some clean up and don't really add any
maintenance effort for the civetweb maintainers.

I already contacted the civetweb author regarding two of the patches.
One was a new one (civetweb now uses a timegm function that we don't
have: https://github.com/civetweb/civetweb/pull/298).

The second one was a more complex one that _could_ lead to maintenance
effort: We (to be exact: I) added some paramters to mongoose to
influence stack size and scheduling. The maintainer of civetweb wasn't
really enthusiastic about the way of the integration. He would prefer
another interface. I tried to invite the RTEMS mailinglist into the
discussion but till now I didn't get any responses:
  https://lists.rtems.org/pipermail/devel/2016-April/014621.html
  https://groups.google.com/forum/#!topic/civetweb/_Mul9PxgpBE

> 
>>  >
>>  > When we do this, we incur some burden of "retraining" users to
>> consider
>>  > a webserver an external addon. But that is the direction I think
>> we want
>>  > to head with httpd, telnetd, ftpd, etc. So it is a good long term
>> goal.
> 
> Agreed.
> 
>>  >
>>  >>
>>  >> Chris, I think you know the RSB best: What steps do you think
>> would be
>>  >> necessary?
>>  >>
>>  >
>>  > Chris...
>>  >
> 
> There are a number of examples that show how to do this. Ping me if you
> need specific help. Gedare has highlighted NTP and there is also NetNSMP.
> 

Civetweb seems to have multiple build systems. One is a most likely
handwritten Makefile
(https://github.com/civetweb/civetweb/blob/master/Makefile). Another
would be cmake. Is there any experience, which build system would be
easier to integrate? Do we have any other non-automake projects?

>>  >>
>>  >> 2. Currently there is one test case for mghttpd
>> (libtests/mghttpd01).
>>  >> This is one of the few tests that check some networking
>> functions in
>>  >> RTEMS.
> 
> I would be concerned if the only way we can do network testing is to
> consume a 3prd party package's source into RTEMS. :)

It's not the only test that tests network functions in RTEMS. But as far
as I know, there are not many. If we remove it, it will be one less.

> 
>> Further we should not loose the ability to test software
>> when it
>>  >> is build with RSB.
> 
> I agree.
> 
>> How would we handle tests for software in RSB?
>>  >>
>>  >
>>  > That's a Chris question. We should aim to have tests which run
>> with
>>  > either network stack for RSB built network services. This is a
>> good
>>  > requirement on the plan to moving to separately built network
>> stacks
>>  > and services.
> 
> Network testing is an open topic as is vertically integrated packages.
> The testing issues exists with libbsd, lwip and the in-tree stack once
> we move out of the source tree. As we flesh out the details of
> vertically integrating packages we need to figure out now to manage
> testing.
> 
> What tests does civetweb provide? If the test is important I would
> assume it is important to all users. Can civetweb build the test?
> 

Civetweb has a number of tests. But I thi

Re: PWM driver tested in RTEMS with RGB

[Martin Galvan]

Hi Punit! Sorry for the delay; I finally got to review your code.
First and foremost, it'd be great if you could tell us which
StarterWare version/git commit are you using, so that we can keep it
handy when reviewing your code. Sorry if you already mentioned it, my
memory is a bit sketchy these days :)

As a general comment I'd say you should keep a consistent coding style
throughout the code you write yourself. While the core RTEMS style
(spaces after parentheses, etc) isn't required in BSP code, at least
indentations should be correct. Indentations in RTEMS are usually two
spaces.

More on coding style later.

On Fri, Apr 15, 2016 at 4:48 PM, punit vara  wrote:
> This is my first patch I already sent you when I successfully merged TI SW 
> code.
>
> https://github.com/punitvara/rtems_gsoc16/tree/master/pwm/patch

I take it you're referring to 0001-add-new-pwm-driver.patch. A few comments:

1) Whenever possible, try to keep the original coding style for
imported code. This makes it easier to track changes and such. Same
goes for e.g. the order in which functions are declared (e.g.
EHRPWMConfigureAQActionOnA and B).

2) I think you should add the TI license to bbb-pwm.c as well. It
would also be really nice if you added a comment atop the imported
files saying which SW version/git commit they come from.

3) Are those REG* macros in the original SW code? I recall having seen
them defined in RTEMS, while SW used HWREG*. If they're from RTEMS,
please generate a patch that adds the vanilla SW code, then a second
one with your changes to adapt it to RTEMS like Gedare suggested. I
saw you already did that with SOC_CONTROL_REGS -> AM335X_PADCONF_BASE.

4) I saw that on bbb-pwm.c you placed functions from different SW
files (e.g. PWMSSModuleClkConfig comes from platform/evmAM335x/pwmss.c
while EHRPWMTimebaseClkConfig comes from drivers/ehrpwm.c). While I
agree that it's not necessary to maintain the exact same file
structure from SW, it'd be nice if you grouped each set of functions
from a SW file together and added a comment atop saying something like
/* These functions come from drivers/ehrpwm.c in TI StarterWare */.
However that's just my opinion; perhaps there's a better way to do
this (Gedare?).

5) I'm seeing your patch includes changes to a couple of M4 files.
This probably comes from a bootstrap, and should be kept off your
final patch.

> 2. Second patch which shows I added useful registers from TI SW header files
>
> https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0002-add-register-for-pwm-driver.patch
>
> After above two patches I created testsuite
>
> https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/fail.c

>From what I'm seeing, your example comes from
examples/evmAM335x/ehrpwm_haptics/ehrpwm_haptics.c, which
drives a Pico-Haptics 304-100 motor that's connected to the
B-Channel of the PWMSS2 of the AM335x EVM. I've taken a look at your
version vs the SW example, and while I can't immediately point out
what's wrong I suspect there may be some register magic your code is
missing, or perhaps some of the values aren't being set correctly. In
any case, double-check the SW example with the AM335x Technical
Reference Manual; don't rule out bugs in SW itself.

> In this testsuite, LED is constantly glowing as I told. No matter what
> counter I set or frequency set I am not able to get expected output.
>
> 3. Then I added three new function that can be seen in below patch.TI
> Copy right is also added as Gedare Bloom suggested me.
>
> https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0001-PWM-successful-code-added.patch

Don't forget to mark the code changes with #if defined(__rtems__) like
Gedare suggested.

> You should look these definition in patch. I wrote this after first
> failed testsuite.
>
> - PWMSS_Setting
> - ehrPWM_Enable
> - ehrPWM_Disable
> - EPWMPinMuxSetup  This last function I also used in first test case.

If you are going to keep those functions I think you should improve
the coding style a bit (e.g. name them using CamelCase as the rest of
SW code, avoid magic numbers, etc).

I think for now we should focus on making your PWM example work using
the SW APIs. If you realize it definitely won't work because the API
has a bug, you should patch the API. All in all, good work!
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 00/13] Replace mongoose with civetweb.

[Chris Johns]

On 26/04/2016 22:22, Christian Mauderer wrote:

Am 26.04.2016 um 04:51 schrieb Chris Johns:

On 26/04/2016 07:22, Joel Sherrill wrote:

Agreed 100%!

NTP has an RSB recipe and there are others for various libraries which
should be good examples. Shouldn't take long to do the recipe. Just ask
questions rather than getting stuck.

On Apr 25, 2016 7:03 PM, "Gedare Bloom" mailto:ged...@rtems.org>> wrote:

 On Mon, Apr 25, 2016 at 11:25 AM, Joel Sherrill mailto:j...@rtems.org>> wrote:
  >
  >
  > On Mon, Apr 25, 2016 at 4:22 AM, Christian Mauderer
  > mailto:christian.maude...@embedded-brains.de>> wrote:
  >>
  >> Essentially I agree that it would be nice to build civetweb as an
  >> external library especially with the different network stacks in
 mind.
  >> But there are some points that keep me from doing it:
  >>
  >> 1. I have really no Idea what would be necessary to build it
as an
  >> upstream project using RSB. If that are only something like
 three simple
  >> steps, it should be possible to squeeze it in the little time
budget
  >> that is left for the project. If I first have to analyze and
 change a
  >> lot of RSB, it would be challenging.
  >>
  > FWIW I think this can be a secondary goal. Switching over to
the real
  > upstream project with proper licensing is important.


I see both as equally important and once the switch is made we have an
on going liability in the project to keep the packaging maintained so
considering it a bit more I suppose the long term issue is actually more
important to me.


There is still some work left before we can use the upstream project. I
more or less took over most of the patches that we applied to mongoose.
Most of them should just need some clean up and don't really add any
maintenance effort for the civetweb maintainers.


Excellent. Thank you so much of doing this.


I already contacted the civetweb author regarding two of the patches.
One was a new one (civetweb now uses a timegm function that we don't
have: https://github.com/civetweb/civetweb/pull/298).

The second one was a more complex one that _could_ lead to maintenance
effort: We (to be exact: I) added some paramters to mongoose to
influence stack size and scheduling. The maintainer of civetweb wasn't
really enthusiastic about the way of the integration. He would prefer
another interface. I tried to invite the RTEMS mailinglist into the
discussion but till now I didn't get any responses:
   https://lists.rtems.org/pipermail/devel/2016-April/014621.html
   https://groups.google.com/forum/#!topic/civetweb/_Mul9PxgpBE


I see. If there exists a risk for Windows, Linux or any platform related 
configuration parameter getting bad values, why not force the value, or 
ignore the user setting, or raise an error on those platforms a 
parameter setting does not work on. This model is consistent, easy, and 
allows a finer per platform control of all parameters. The documentation 
for configuration is in a single location.


I have been looking after a mongoose set up for a client someone else 
set up. There has now been a couple of sets of eyes looking at the 
configuration and making minor tweaks. If there was another call-back, 
or overloaded define interface being used we would never have found it.


It would be a shame to add a call-back interface because the 
configuration becomes split and integration becomes disjointed. Also 
these days I prefer weak symbols over call-backs. Overloading the define 
with a call-out is tricky and hidden and it leaks internal details as a 
published interface.







  >
  > When we do this, we incur some burden of "retraining" users to
 consider
  > a webserver an external addon. But that is the direction I think
 we want
  > to head with httpd, telnetd, ftpd, etc. So it is a good long term
 goal.


Agreed.


  >
  >>
  >> Chris, I think you know the RSB best: What steps do you think
 would be
  >> necessary?
  >>
  >
  > Chris...
  >


There are a number of examples that show how to do this. Ping me if you
need specific help. Gedare has highlighted NTP and there is also NetNSMP.



Civetweb seems to have multiple build systems. One is a most likely
handwritten Makefile
(https://github.com/civetweb/civetweb/blob/master/Makefile). Another
would be cmake. Is there any experience, which build system would be
easier to integrate? Do we have any other non-automake projects?


Either can be made to work. I have no problem with cmake but I have it 
installed for other work so I am ok. Using cmake would make it a 
dependency for the RSB.


If you can supply a simple set of shell commands we should be able to 
bake an RSB recipe.


Also with patches, I recently added a change to the RSB that allows us 
to use patches from mailing list archives. This means a post to a list 
can be referenced and we do not need to include patches in the

Re: [rtems-libbsd commit] Add root bus support functions

[Chris Johns]

On 26/04/2016 23:22, Sebastian Huber wrote:


Add root bus support functions



How and why would you use these functions?

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

Re: Draft for moving network headers from RTEMS to newlib

[Chris Johns]

On 26/04/2016 19:26, Sebastian Huber wrote:



On 26/04/16 10:27, Chris Johns wrote:

On 26/04/2016 17:31, Sebastian Huber wrote:

On 26/04/16 07:51, Chris Johns wrote:

On 26/04/2016 01:06, Christian Mauderer wrote:

currently we try to remove the network specific POSIX headers from
RTEMS. Instead, we add current headers from FreeBSD to newlib. This
will
simplify the build process of some libraries that depend on the
network
(like LibreSSL).


What does this work flow offer over building and installing an RTEMS
kernel for a BSP and adding that path to the packages include paths?


You don't build per BSP in this scenario. You build per multilib and
have only one set of header files installed.


Hmm multilib, this is what I thought was happening. I see this
exploding the libraries if packages are built this way. Do we manage
this or not bother and just accept all variants have to be built?


The multilibs are there for a purpose. In case a particular architecture
has superfluous multilibs, then we should remove them.


I have no idea which variants of each architecture are actually used. I 
suspect we need to document this better.


I see clang has better support for multilib than in the past ...

$ clang -print-multi-lib
.;
x86_64;@m64

This is nice.


I see an
explosion of libraries if we build them for each BSP. We have count of
BSPs > count of multilibs, otherwise the GCC configuration is broken.


This is only valid for developers who have to build all BSPS. Most uses 
have one or maybe 2 BSPs they are working with at a time.


My question was, do we care about this? You do not see it as an issue 
because your need to package built tools and libraries is important, and 
I can live with it cause I have fast machines and fast disks but we are 
just 2 people.


FYI there are 11 variants in ARM.






You are able to use the
network header files during GCC build, which makes it easier to build
the run-time libraries of Ada and Go.


Nice. Maybe limiting what is added to just building languages would be
a nice first starting point.





How do you get the flags for the compiler to build the package?


See attached script which builds for example libpng for all multilibs.


Multilibs has not had a very successful history with RTEMS (outside of
gcc). They are not very user friendly and are a source of questions
and issues.


I think multilibs are great for libraries which don't depend on BSP
specifics.


I know ...

https://lists.rtems.org/pipermail/users/2012-February/024544.html

:)

It is a useful idea and I like the work being done with the standards 
based headers.


There is something inconsistent about this I am yet to put my finger on. 
I suspect it is related to some libraries being multilib and some 
libraries not being multilib. Consider an example app and lets assume 
all packages are working perfectly ..


1) GCC, newlib.  - Multilib,   /bd/rtems/4.11.0
2) RTEMS - Specific,   /bd/rtems/4.11.0/bsps
3) NTP   - Multilib,   /bd/rtems/4.11.0/bsps
4) Protobufs - Multilib,   /bd/rtems/4.11.0/bsps
5) Civetweb  - Multilib,   /bd/rtems/4.11.0/bsps
6) NetSNMP   - Specific,   /bd/rtems/4.11.0/bsps
7) Application   - Executable

I wonder what the application linker command line looks like?

Does gcc's multilib search extend beyond it's own install base?

The NetSNMP package is put here as Specific because it uses a large 
number of platform specific header files to access things like 
interfaces and routing tables.


My point is, when a user considers 3rd party packages they have moved to 
the specific requirements for a specific project and multilibs verses 
per BSP builds mean little. The multilib view is nice when viewed from 
the RTEMS developer perspective or someone providing a service to 
clients where they bundle packages as prebuilt libraries, but is it nice 
to users from the community? I do not know. If both multilib and 
specific libraries can coexist I have no issue but this needs to be shown.


Note, the layout is based on the Project Sandboxing documentation I have 
in the Getting Started Guide 
(https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/start/index.html#project-sandboxing). 
This documentation would need to be updated (hint).



What is the benefit of per BSP libpng for example?


What is built is tested, there is a 1:1 relationship here. The user is 
able to see and understand what is built, where it is installed and what 
they are linking too. Multilibing packages adds a layer of indirection 
and with that extra complexity.


Multilibs in gcc is not very user friendly 

$ i386-rtems4.11-gcc -print-multi-lib
.;
m486;@mtune=i486
mpentium;@mtune=pentium
mpentiumpro;@mtune=pentiumpro
soft-float;@msoft-float
m486/soft-float;@mtune=i486@msoft-float

$ arm-rtems4.11-gcc -print-multi-lib
.;
thumb;@mthumb
thumb/armv6-m;@mthumb@march=armv6-m
thumb/armv7-a;@mthumb@march=armv7-a
thumb/armv7-r;@mthumb@march=armv7-r
thumb/armv7-m;@mthumb@march=armv7-m
thumb/

[PATCH] fix-warning: fix it to fit c90.

[DU HUANPENG]

From: Du Huanpeng 

---
 cpukit/score/cpu/arm/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/score/cpu/arm/cpu.c b/cpukit/score/cpu/arm/cpu.c
index 944ca63..c9dc22e 100644
--- a/cpukit/score/cpu/arm/cpu.c
+++ b/cpukit/score/cpu/arm/cpu.c
@@ -135,8 +135,8 @@ void _CPU_ISR_Set_level( uint32_t level )
 
 uint32_t _CPU_ISR_Get_level( void )
 {
-  ARM_SWITCH_REGISTERS;
   uint32_t level;
+  ARM_SWITCH_REGISTERS;
 
   __asm__ volatile (
 ARM_SWITCH_TO_ARM
-- 
2.7.4


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

Re: [rtems-libbsd commit] Add root bus support functions

[Sebastian Huber]

On 27/04/16 04:27, Chris Johns wrote:

On 26/04/2016 23:22, Sebastian Huber wrote:


Add root bus support functions



How and why would you use these functions?


/**
 * @brief Attach the root bus.
 *
 * @retval 0 Successful operation.
 * @retval errno Otherwise.
 */
int rtems_bsd_bus_root_attach(void);

/**
 * @brief Suspend the root bus.
 *
 * @retval 0 Successful operation.
 * @retval errno Otherwise.
 */
int rtems_bsd_bus_root_suspend(void);

/**
 * @brief Resume the root bus.
 *
 * @retval 0 Successful operation.
 * @retval errno Otherwise.
 */
int rtems_bsd_bus_root_resume(void);

/**
 * @brief Detach the root bus.
 *
 * @retval 0 Successful operation.
 * @retval errno Otherwise.
 */
int rtems_bsd_bus_root_detach(void);

Suspend and resume can be used to go into a power saving state. Detach 
to shutdown the system and do a warm reset.


--
Sebastian Huber, embedded brains GmbH

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

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: Draft for moving network headers from RTEMS to newlib

[Sebastian Huber]

On 27/04/16 05:53, Chris Johns wrote:

On 26/04/2016 19:26, Sebastian Huber wrote:



On 26/04/16 10:27, Chris Johns wrote:

On 26/04/2016 17:31, Sebastian Huber wrote:

On 26/04/16 07:51, Chris Johns wrote:

On 26/04/2016 01:06, Christian Mauderer wrote:

[...]

I see an
explosion of libraries if we build them for each BSP. We have count of
BSPs > count of multilibs, otherwise the GCC configuration is broken.


This is only valid for developers who have to build all BSPS. Most 
uses have one or maybe 2 BSPs they are working with at a time.


My question was, do we care about this? You do not see it as an issue 
because your need to package built tools and libraries is important, 
and I can live with it cause I have fast machines and fast disks but 
we are just 2 people.


I think its quite nice if you are able to build support libraries as a 
part of the tool chain and not specific to a particular BSP.




FYI there are 11 variants in ARM.


Yes, and we need them all.








You are able to use the
network header files during GCC build, which makes it easier to build
the run-time libraries of Ada and Go.


Nice. Maybe limiting what is added to just building languages would be
a nice first starting point.





How do you get the flags for the compiler to build the package?


See attached script which builds for example libpng for all multilibs.


Multilibs has not had a very successful history with RTEMS (outside of
gcc). They are not very user friendly and are a source of questions
and issues.


I think multilibs are great for libraries which don't depend on BSP
specifics.


I know ...

https://lists.rtems.org/pipermail/users/2012-February/024544.html

:)

It is a useful idea and I like the work being done with the standards 
based headers.


There is something inconsistent about this I am yet to put my finger 
on. I suspect it is related to some libraries being multilib and some 
libraries not being multilib. Consider an example app and lets assume 
all packages are working perfectly ..


1) GCC, newlib.  - Multilib,   /bd/rtems/4.11.0
2) RTEMS - Specific,   /bd/rtems/4.11.0/bsps
3) NTP   - Multilib,   /bd/rtems/4.11.0/bsps
4) Protobufs - Multilib,   /bd/rtems/4.11.0/bsps
5) Civetweb  - Multilib,   /bd/rtems/4.11.0/bsps
6) NetSNMP   - Specific,   /bd/rtems/4.11.0/bsps
7) Application   - Executable

I wonder what the application linker command line looks like?

Does gcc's multilib search extend beyond it's own install base?


A multilib is a normal library which is available via the builtin search 
paths of GCC:


LIBRARY_PATH=/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/



The NetSNMP package is put here as Specific because it uses a large 
number of platform specific header files to access things like 
interfaces and routing tables.


My point is, when a user considers 3rd party packages they have moved 
to the specific requirements for a specific project and multilibs 
verses per BSP builds mean little. The multilib view is nice when 
viewed from the RTEMS developer perspective or someone providing a 
service to clients where they bundle packages as prebuilt libraries, 
but is it nice to users from the community? I do not know. If both 
multilib and specific libraries can coexist I have no issue but this 
needs to be shown.


Note, the layout is based on the Project Sandboxing documentation I 
have in the Getting Started Guide 
(https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/start/index.html#project-sandboxing). 
This documentation would need to be updated (hint).



What is the benefit of per BSP libpng for example?


What is built is tested, there is a 1:1 relationship here. The user is 
able to see and understand what is built, where it is installed and 
what they are linking too. Multilibing packages adds a layer of 
indirection and with that extra complexity.


Multilibs in gcc is not very user friendly 

$ i386-rtems4.11-gcc -print-multi-lib
.;
m486;@mtune=i486
mpentium;@mtune=pentium
mpentiumpro;@mtune=pentiumpro
soft-float;@msoft-float
m486/soft-float;@mtune=i486@msoft-float


The output is just like the clang output. What do you mean with not user 
friendly? Its good enough to simply use it in the previously attached 
script.




$ arm-rtems4.11-gcc -print-multi-lib
.;
thumb;@mthumb
thumb/armv6-m;@mthumb@march=armv6-m
thumb/armv7-a;@mthumb@march=armv7-a
thumb/armv7-r;@mthumb@march=armv7-r
thumb/armv7-m;@mthumb@march=armv7-m
thumb/armv7-a/neon/hard;@mthumb@march=armv7-a@mfpu=neon@mfloat-abi=hard
thumb/armv7-r/vfpv3-d16/hard;@mthumb@march=armv7-r@mfpu=vfpv3-d16@mfloat-abi=hard 

thumb/armv7-m/fpv4-sp-d16/hard;@mthumb@march=armv7-m@mfpu=fpv4-sp-d16@mfloat-abi=hard 


eb/thumb/armv7-r;@mbig-endian@mthumb@march=armv7-r
eb/thumb

Re: [rtems-libbsd commit] Add root bus support functions

[Chris Johns]

On 27/04/2016 15:53, Sebastian Huber wrote:

Suspend and resume can be used to go into a power saving state. Detach
to shutdown the system and do a warm reset.


I can make these calls safely from my application at any time?

Chris

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

Re: [rtems-libbsd commit] Add root bus support functions

[Sebastian Huber]

On 27/04/16 07:59, Chris Johns wrote:

On 27/04/2016 15:53, Sebastian Huber wrote:

Suspend and resume can be used to go into a power saving state. Detach
to shutdown the system and do a warm reset.


I can make these calls safely from my application at any time? 


If all drivers are written properly and you call these functions in task 
context (like all other libbsd functions) and your application blocks no 
resources used by your drivers.


--
Sebastian Huber, embedded brains GmbH

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

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [rtems-libbsd commit] Add root bus support functions

[Chris Johns]

On 27/04/2016 16:02, Sebastian Huber wrote:

On 27/04/16 07:59, Chris Johns wrote:

On 27/04/2016 15:53, Sebastian Huber wrote:

Suspend and resume can be used to go into a power saving state. Detach
to shutdown the system and do a warm reset.


I can make these calls safely from my application at any time?


If all drivers are written properly and you call these functions in task
context (like all other libbsd functions) and your application blocks no
resources used by your drivers.



Thank you. Do you think some comments in the code that says this would 
be a good idea?


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

Re: Draft for moving network headers from RTEMS to newlib

[Chris Johns]

On 27/04/2016 15:58, Sebastian Huber wrote:

On 27/04/16 05:53, Chris Johns wrote:

On 26/04/2016 19:26, Sebastian Huber wrote:

On 26/04/16 10:27, Chris Johns wrote:

On 26/04/2016 17:31, Sebastian Huber wrote:

On 26/04/16 07:51, Chris Johns wrote:

On 26/04/2016 01:06, Christian Mauderer wrote:

[...]



You are able to use the
network header files during GCC build, which makes it easier to build
the run-time libraries of Ada and Go.


Nice. Maybe limiting what is added to just building languages would be
a nice first starting point.





How do you get the flags for the compiler to build the package?


See attached script which builds for example libpng for all multilibs.


Multilibs has not had a very successful history with RTEMS (outside of
gcc). They are not very user friendly and are a source of questions
and issues.


I think multilibs are great for libraries which don't depend on BSP
specifics.


I know ...

https://lists.rtems.org/pipermail/users/2012-February/024544.html

:)

It is a useful idea and I like the work being done with the standards
based headers.

There is something inconsistent about this I am yet to put my finger
on. I suspect it is related to some libraries being multilib and some
libraries not being multilib. Consider an example app and lets assume
all packages are working perfectly ..

1) GCC, newlib.  - Multilib,   /bd/rtems/4.11.0
2) RTEMS - Specific,   /bd/rtems/4.11.0/bsps
3) NTP   - Multilib,   /bd/rtems/4.11.0/bsps
4) Protobufs - Multilib,   /bd/rtems/4.11.0/bsps
5) Civetweb  - Multilib,   /bd/rtems/4.11.0/bsps
6) NetSNMP   - Specific,   /bd/rtems/4.11.0/bsps
7) Application   - Executable

I wonder what the application linker command line looks like?

Does gcc's multilib search extend beyond it's own install base?


A multilib is a normal library which is available via the builtin search
paths of GCC:

LIBRARY_PATH=/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/



Does this mean all multilib libraries need the same prefix as gcc?





The NetSNMP package is put here as Specific because it uses a large
number of platform specific header files to access things like
interfaces and routing tables.

My point is, when a user considers 3rd party packages they have moved
to the specific requirements for a specific project and multilibs
verses per BSP builds mean little. The multilib view is nice when
viewed from the RTEMS developer perspective or someone providing a
service to clients where they bundle packages as prebuilt libraries,
but is it nice to users from the community? I do not know. If both
multilib and specific libraries can coexist I have no issue but this
needs to be shown.

Note, the layout is based on the Project Sandboxing documentation I
have in the Getting Started Guide
(https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/start/index.html#project-sandboxing).
This documentation would need to be updated (hint).


What is the benefit of per BSP libpng for example?


What is built is tested, there is a 1:1 relationship here. The user is
able to see and understand what is built, where it is installed and
what they are linking too. Multilibing packages adds a layer of
indirection and with that extra complexity.

Multilibs in gcc is not very user friendly 

$ i386-rtems4.11-gcc -print-multi-lib
.;
m486;@mtune=i486
mpentium;@mtune=pentium
mpentiumpro;@mtune=pentiumpro
soft-float;@msoft-float
m486/soft-float;@mtune=i486@msoft-float


The output is just like the clang output.


I suspect clang was forced to follow gcc. :)


What do you mean with not user friendly?


It is designed to be machine decoded. I suspect few on this list could 
decode that output and understand it and this is the interface a user 
gets if they want to use it.



Its good enough to simply use it in the previously attached script.


I think RTEMS has to do much better than 'hey hack on my script'.





$ arm-rtems4.11-gcc -print-multi-lib
.;
thumb;@mthumb
thumb/armv6-m;@mthumb@march=armv6-m
thumb/armv7-a;@mthumb@march=armv7-a
thumb/armv7-r;@mthumb@march=armv7-r
thumb/armv7-m;@mthumb@march=armv7-m
thumb/armv7-a/neon/hard;@mthumb@march=armv7-a@mfpu=neon@mfloat-abi=hard
thumb/armv7-r/vfpv3-d16/hard;@mthumb@march=armv7-r@mfpu=vfpv3-d16@mfloat-abi=hard

thumb/armv7-m/fpv4-sp-d16/hard;@mthumb@march=armv7-m@mfpu=fpv4-sp-d16@mfloat-abi=hard

eb/thumb/armv7-r;@mbig-endian@mthumb@march=armv7-r
eb/thumb/armv7-r/vfpv3-d16/hard;@mbig-endian@mthumb@march=armv7-r@mfpu=vfpv3-d16@mfloat-abi=hard


I have no idea what this all means.


One problem is that even you don't find the places where things are
documented in RTEMS:

https://docs.rtems.org/doc-current/share/rtems/html/cpu_supplement/Port-Specific-Information-Multilibs.html#Port-Specific-Informati

Re: Draft for moving network headers from RTEMS to newlib

[Sebastian Huber]

On 27/04/16 08:20, Chris Johns wrote:

On 27/04/2016 15:58, Sebastian Huber wrote:

On 27/04/16 05:53, Chris Johns wrote:

On 26/04/2016 19:26, Sebastian Huber wrote:

On 26/04/16 10:27, Chris Johns wrote:

On 26/04/2016 17:31, Sebastian Huber wrote:

On 26/04/16 07:51, Chris Johns wrote:

On 26/04/2016 01:06, Christian Mauderer wrote:

[...]

Does gcc's multilib search extend beyond it's own install base?


A multilib is a normal library which is available via the builtin search
paths of GCC:

LIBRARY_PATH=/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/ 





Does this mean all multilib libraries need the same prefix as gcc?


Yes, as far as I know.







The NetSNMP package is put here as Specific because it uses a large
number of platform specific header files to access things like
interfaces and routing tables.

My point is, when a user considers 3rd party packages they have moved
to the specific requirements for a specific project and multilibs
verses per BSP builds mean little. The multilib view is nice when
viewed from the RTEMS developer perspective or someone providing a
service to clients where they bundle packages as prebuilt libraries,
but is it nice to users from the community? I do not know. If both
multilib and specific libraries can coexist I have no issue but this
needs to be shown.

Note, the layout is based on the Project Sandboxing documentation I
have in the Getting Started Guide
(https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/start/index.html#project-sandboxing). 


This documentation would need to be updated (hint).


What is the benefit of per BSP libpng for example?


What is built is tested, there is a 1:1 relationship here. The user is
able to see and understand what is built, where it is installed and
what they are linking too. Multilibing packages adds a layer of
indirection and with that extra complexity.

Multilibs in gcc is not very user friendly 

$ i386-rtems4.11-gcc -print-multi-lib
.;
m486;@mtune=i486
mpentium;@mtune=pentium
mpentiumpro;@mtune=pentiumpro
soft-float;@msoft-float
m486/soft-float;@mtune=i486@msoft-float


The output is just like the clang output.


I suspect clang was forced to follow gcc. :)


What do you mean with not user friendly?


It is designed to be machine decoded. I suspect few on this list could 
decode that output and understand it and this is the interface a user 
gets if they want to use it.



Its good enough to simply use it in the previously attached script.


I think RTEMS has to do much better than 'hey hack on my script'.


This was not my intended message. The GCC -print-multi-lib output is 
good enough to be easily used by scripts.


[...]

except that you see standard network headers even if the BSP is
built without a network stack.


Does this mess with the dummy.c support and create weird linker errors?


I don't think this will pull in default-configuration (previously know 
as dummy.c). If you use socket() without a network stack, then you get 
an unresolved symbol to socket() linker error. default-configuration.c 
is only involved if you use a module and don't provide the module 
configuration.




I assume all externals in the headers moved over have to have symbols 
added.



We should come to a conclusion if we want the standard network headers
in Newlib or not.


There are 2 threads happening here. The benefit or impact of multibed 
libraries and the move to newlib of standard headers. I am ok with the 
header move. I am sure things will come up but I am also sure they can 
be addressed. The impact of multilibed library can consider mute 
because you have answer my central question which is both models for 
libraries can be supported.


You can provide a library in a multilib directory or in a BSP-specific 
directory or in whatever directory you want to use. The linker search 
path determines which one is actually used.


--
Sebastian Huber, embedded brains GmbH

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

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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