Re: [PATCH rtems-libbsd] libbsd.py: Install the evdev header files

[Vijay Kumar Banerjee]

On Fri, Jun 5, 2020 at 9:34 AM Sebastian Huber
 wrote:
>
> Ok.
>
Thanks. Pushed to master.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

[Jan.Sommer]

Hello,

We came across the PPSi library for PTP support some time ago: 
https://ohwr.org/project/ppsi
In their documentation its says they started with ptpd and then made an 
overhaul of the source code.
They also claim portability as one of their goals. We haven't had time to look 
at it closer yet, but the projects looks a bit more active and seems to have 
the CERN behind it.
Maybe it is worth checking out, if ptpd keeps making trouble.

Cheers,

Jan


> -Original Message-
> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian
> Huber
> Sent: Friday, June 5, 2020 6:09 AM
> To: Mritunjay Sharma
> Cc: RTEMS Devel
> Subject: Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This
> time building for xilinx_zynq_a9_qemu
> 
> On 04/06/2020 20:29, Mritunjay Sharma wrote:
> 
> >
> >
> > On Thu, Jun 4, 2020 at 11:07 PM Sebastian Huber
> >  > > wrote:
> >
> > On 04/06/2020 16:22, Gedare Bloom wrote:
> >
> > >>> In the github version this code is conditional on sys/cpuset.h
> > being present.
> > >>>
> > > Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
> > > definitions though. Probably either:
> > > 1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
> > > would mean adding cpuset_setaffinity support in rtems, I guess.
> > > 2. Figure out how to disable the conditional code using the
> > > cpuset_setaffinity function.
> > The  is already as compatible as possible to glibc and
> > FreeBSD. There is always room for improvement, however, in this
> > area it
> > will be difficult.
> >
> >
> > Please it would be kind of you all to guide on what is the best thing
> > I can do next. It is looking
> > a little difficult. If something similar has been done earlier,
> > sharing it can be a lot helpful to take a cue.
> 
> Configure scripts are sometimes confused that Newlib provides the glibc
> and FreeBSD CPU set APIs. In this case it seems a FreeBSD system was
> detected and it tries to use some proprietary system calls such as
> cpuset_setaffinity(). If you encounter things like this, I would look at
> the man page:
> 
> https://www.freebsd.org/cgi/man.cgi?query=cpuset_setaffinity&apropos=0
> &sektion=0&manpath=FreeBSD+12.1-RELEASE&arch=default&format=html
> 
> Then you have to evaluate if this stuff makes sense on RTEMS. Is it
> really needed? Otherwise you can disable it via an #ifndef __rtems__ define.
> 
> ___
> 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 rtems-littlevgl 4/4] lv_drv_conf: Enable USE_BSD_EVDEV option

[Christian Mauderer]

Hello Vijay,

On 04/06/2020 20:44, Vijay Kumar Banerjee wrote:
> ---
>  lv_drv_conf.h | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/lv_drv_conf.h b/lv_drv_conf.h
> index 697ceaf..e8d2c40 100644
> --- a/lv_drv_conf.h
> +++ b/lv_drv_conf.h
> @@ -322,7 +322,11 @@
>  #  define USE_EVDEV   0
>  #endif
>  
> -#if USE_EVDEV
> +#ifndef USE_BSD_EVDEV
> +#  define USE_BSD_EVDEV   1
> +#endif

I haven't tested it and haven't had a detailed look. But first question
that springs to my mind: Can we still use no evdev on targets without it
with this change? Or becomes some evdev module for libbsd mandatory with
it if you want to use lvgl?

Best regards

Christian

> +
> +#if USE_EVDEV || USE_BSD_EVDEV
>  #  define EVDEV_NAME   "/dev/input/event0"/*You can use the "evtest" 
> Linux tool to get the list of devices and test them*/
>  #  define EVDEV_SWAP_AXES 0   /*Swap the x and y axes of 
> the touchscreen*/
>  
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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: [PATCH rtems-littlevgl 1/4] update lv_drivers submodule url

[Christian Mauderer]

On 04/06/2020 20:44, Vijay Kumar Banerjee wrote:
> ---
>  .gitmodules | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/.gitmodules b/.gitmodules
> index 5bf0006..69d2d5c 100644
> --- a/.gitmodules
> +++ b/.gitmodules
> @@ -1,6 +1,6 @@
>  [submodule "lv_drivers"]
>   path = lv_drivers
> - url = https://github.com/littlevgl/lv_drivers.git
> + url = https://github.com/lvgl/lv_drivers.git

The name of the project changed. Do the other submodules require an
update too?

>  [submodule "lvgl"]
>   path = lvgl
>   url = https://github.com/littlevgl/lvgl.git
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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: [PATCH rtems-littlevgl 1/4] update lv_drivers submodule url

[Vijay Kumar Banerjee]

On Fri, Jun 5, 2020 at 2:00 PM Christian Mauderer
 wrote:
>
>
> On 04/06/2020 20:44, Vijay Kumar Banerjee wrote:
> > ---
> >  .gitmodules | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/.gitmodules b/.gitmodules
> > index 5bf0006..69d2d5c 100644
> > --- a/.gitmodules
> > +++ b/.gitmodules
> > @@ -1,6 +1,6 @@
> >  [submodule "lv_drivers"]
> >   path = lv_drivers
> > - url = https://github.com/littlevgl/lv_drivers.git
> > + url = https://github.com/lvgl/lv_drivers.git
>
> The name of the project changed. Do the other submodules require an
> update too?
>
Hi,

Yes, the lvgl submodule will require an update too. I'll add it to
this patch and send a v2.

Thanks
> >  [submodule "lvgl"]
> >   path = lvgl
> >   url = https://github.com/littlevgl/lvgl.git
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> 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: [PATCH rtems-littlevgl 4/4] lv_drv_conf: Enable USE_BSD_EVDEV option

[Vijay Kumar Banerjee]

On Fri, Jun 5, 2020 at 1:59 PM Christian Mauderer
 wrote:
>
> Hello Vijay,
>
> On 04/06/2020 20:44, Vijay Kumar Banerjee wrote:
> > ---
> >  lv_drv_conf.h | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/lv_drv_conf.h b/lv_drv_conf.h
> > index 697ceaf..e8d2c40 100644
> > --- a/lv_drv_conf.h
> > +++ b/lv_drv_conf.h
> > @@ -322,7 +322,11 @@
> >  #  define USE_EVDEV   0
> >  #endif
> >
> > -#if USE_EVDEV
> > +#ifndef USE_BSD_EVDEV
> > +#  define USE_BSD_EVDEV   1
> > +#endif
>
Hi!

> I haven't tested it and haven't had a detailed look. But first question
> that springs to my mind: Can we still use no evdev on targets without it
> with this change? Or becomes some evdev module for libbsd mandatory with
> it if you want to use lvgl?
>
With this change in the configuration, the evdev module will be
required to compile as it includes the evdev header files if this
option is set, just like in the case of fbdev. The build options still
remain same, so we can add --no-drivers and these files won't be
touched during the build. If it needs to be further broken down in
such a manner that the fbdev is required but not evdev, then I think
we can keep this option enabled and check it during waf configuration
if evdev is available. If not, we can skill building the evdev files.

Do you think such checking would be necessary or would it be
sufficient to have the --no-drivers option? I'll work on it
accordingly if more options are required.

Thanks for the review.

Best regards,
Vijay
> Best regards
>
> Christian
>
> > +
> > +#if USE_EVDEV || USE_BSD_EVDEV
> >  #  define EVDEV_NAME   "/dev/input/event0"/*You can use the 
> > "evtest" Linux tool to get the list of devices and test them*/
> >  #  define EVDEV_SWAP_AXES 0   /*Swap the x and y axes 
> > of the touchscreen*/
> >
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> 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: [PATCH rtems-littlevgl 4/4] lv_drv_conf: Enable USE_BSD_EVDEV option

[Christian Mauderer]

On 05/06/2020 12:29, Vijay Kumar Banerjee wrote:
> On Fri, Jun 5, 2020 at 1:59 PM Christian Mauderer
>  wrote:
>>
>> Hello Vijay,
>>
>> On 04/06/2020 20:44, Vijay Kumar Banerjee wrote:
>>> ---
>>>  lv_drv_conf.h | 6 +-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lv_drv_conf.h b/lv_drv_conf.h
>>> index 697ceaf..e8d2c40 100644
>>> --- a/lv_drv_conf.h
>>> +++ b/lv_drv_conf.h
>>> @@ -322,7 +322,11 @@
>>>  #  define USE_EVDEV   0
>>>  #endif
>>>
>>> -#if USE_EVDEV
>>> +#ifndef USE_BSD_EVDEV
>>> +#  define USE_BSD_EVDEV   1
>>> +#endif
>>
> Hi!
> 
>> I haven't tested it and haven't had a detailed look. But first question
>> that springs to my mind: Can we still use no evdev on targets without it
>> with this change? Or becomes some evdev module for libbsd mandatory with
>> it if you want to use lvgl?
>>
> With this change in the configuration, the evdev module will be
> required to compile as it includes the evdev header files if this
> option is set, just like in the case of fbdev. The build options still
> remain same, so we can add --no-drivers and these files won't be
> touched during the build. If it needs to be further broken down in
> such a manner that the fbdev is required but not evdev, then I think
> we can keep this option enabled and check it during waf configuration
> if evdev is available. If not, we can skill building the evdev files.
> 
> Do you think such checking would be necessary or would it be
> sufficient to have the --no-drivers option? I'll work on it
> accordingly if more options are required.

First: --no-drivers should be enough for now.

On the long term, I think we should slowly move to a better
configurability. I'm not sure yet how that could look. The method that
we use to build littlevgl is a bit limiting. The library has a quite
fixed configuration (the lv_conf.h). For example if you want to use a
different color depth than 16 bit, you have to adapt the build. If you
want to use a different maximum resulution, you have to adapt the build.

That's quite limiting. Either the settings in our repository match your
requirements or you have to build the library yourself. It would be
great if we could get a bit of more flexibility. Of course some of these
points can't really be changed easily. It's just how littlevgl works.

But it's the reason that I'm a bit careful when we add something that
adds further restrictions. We maybe end up with a really nice build
system that can build the library for exactly one demo application.

The drivers part is a quite separate and less critical one. So
--no-drivers should be OK for that. So feel free to go on with it.

Best regards

Christian

> 
> Thanks for the review.
> 
> Best regards,
> Vijay
>> Best regards
>>
>> Christian
>>
>>> +
>>> +#if USE_EVDEV || USE_BSD_EVDEV
>>>  #  define EVDEV_NAME   "/dev/input/event0"/*You can use the 
>>> "evtest" Linux tool to get the list of devices and test them*/
>>>  #  define EVDEV_SWAP_AXES 0   /*Swap the x and y axes 
>>> of the touchscreen*/
>>>
>>>
>>
>> --
>> 
>> embedded brains GmbH
>> Herr Christian Mauderer
>> Dornierstr. 4
>> D-82178 Puchheim
>> Germany
>> email: christian.maude...@embedded-brains.de
>> Phone: +49-89-18 94 741 - 18
>> Fax:   +49-89-18 94 741 - 08
>> PGP: Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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: [PATCH rtems-littlevgl 1/4] update lv_drivers submodule url

[Christian Mauderer]

On 05/06/2020 12:13, Vijay Kumar Banerjee wrote:
> On Fri, Jun 5, 2020 at 2:00 PM Christian Mauderer
>  wrote:
>>
>>
>> On 04/06/2020 20:44, Vijay Kumar Banerjee wrote:
>>> ---
>>>  .gitmodules | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/.gitmodules b/.gitmodules
>>> index 5bf0006..69d2d5c 100644
>>> --- a/.gitmodules
>>> +++ b/.gitmodules
>>> @@ -1,6 +1,6 @@
>>>  [submodule "lv_drivers"]
>>>   path = lv_drivers
>>> - url = https://github.com/littlevgl/lv_drivers.git
>>> + url = https://github.com/lvgl/lv_drivers.git
>>
>> The name of the project changed. Do the other submodules require an
>> update too?
>>
> Hi,
> 
> Yes, the lvgl submodule will require an update too. I'll add it to
> this patch and send a v2.
> 
> Thanks

Great. Feel free to push as soon as you think that it is ready.

>>>  [submodule "lvgl"]
>>>   path = lvgl
>>>   url = https://github.com/littlevgl/lvgl.git
>>>
>>
>> --
>> 
>> embedded brains GmbH
>> Herr Christian Mauderer
>> Dornierstr. 4
>> D-82178 Puchheim
>> Germany
>> email: christian.maude...@embedded-brains.de
>> Phone: +49-89-18 94 741 - 18
>> Fax:   +49-89-18 94 741 - 08
>> PGP: Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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: [PATCH rtems-littlevgl 1/4] update lv_drivers submodule url

[Vijay Kumar Banerjee]

On Fri, Jun 5, 2020 at 4:44 PM Christian Mauderer
 wrote:
>
> On 05/06/2020 12:13, Vijay Kumar Banerjee wrote:
> > On Fri, Jun 5, 2020 at 2:00 PM Christian Mauderer
> >  wrote:
> >>
> >>
> >> On 04/06/2020 20:44, Vijay Kumar Banerjee wrote:
> >>> ---
> >>>  .gitmodules | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/.gitmodules b/.gitmodules
> >>> index 5bf0006..69d2d5c 100644
> >>> --- a/.gitmodules
> >>> +++ b/.gitmodules
> >>> @@ -1,6 +1,6 @@
> >>>  [submodule "lv_drivers"]
> >>>   path = lv_drivers
> >>> - url = https://github.com/littlevgl/lv_drivers.git
> >>> + url = https://github.com/lvgl/lv_drivers.git
> >>
> >> The name of the project changed. Do the other submodules require an
> >> update too?
> >>
> > Hi,
> >
> > Yes, the lvgl submodule will require an update too. I'll add it to
> > this patch and send a v2.
> >
> > Thanks
>
> Great. Feel free to push as soon as you think that it is ready.
>
Thanks for the reviews. Pushed!
> >>>  [submodule "lvgl"]
> >>>   path = lvgl
> >>>   url = https://github.com/littlevgl/lvgl.git
> >>>
> >>
> >> --
> >> 
> >> embedded brains GmbH
> >> Herr Christian Mauderer
> >> Dornierstr. 4
> >> D-82178 Puchheim
> >> Germany
> >> email: christian.maude...@embedded-brains.de
> >> Phone: +49-89-18 94 741 - 18
> >> Fax:   +49-89-18 94 741 - 08
> >> PGP: Public key available on request.
> >>
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> 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: [PATCH rtems-littlevgl 4/4] lv_drv_conf: Enable USE_BSD_EVDEV option

[Vijay Kumar Banerjee]

On Fri, Jun 5, 2020 at 4:42 PM Christian Mauderer
 wrote:
>
> On 05/06/2020 12:29, Vijay Kumar Banerjee wrote:
> > On Fri, Jun 5, 2020 at 1:59 PM Christian Mauderer
> >  wrote:
> >>
> >> Hello Vijay,
> >>
> >> On 04/06/2020 20:44, Vijay Kumar Banerjee wrote:
> >>> ---
> >>>  lv_drv_conf.h | 6 +-
> >>>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/lv_drv_conf.h b/lv_drv_conf.h
> >>> index 697ceaf..e8d2c40 100644
> >>> --- a/lv_drv_conf.h
> >>> +++ b/lv_drv_conf.h
> >>> @@ -322,7 +322,11 @@
> >>>  #  define USE_EVDEV   0
> >>>  #endif
> >>>
> >>> -#if USE_EVDEV
> >>> +#ifndef USE_BSD_EVDEV
> >>> +#  define USE_BSD_EVDEV   1
> >>> +#endif
> >>
> > Hi!
> >
> >> I haven't tested it and haven't had a detailed look. But first question
> >> that springs to my mind: Can we still use no evdev on targets without it
> >> with this change? Or becomes some evdev module for libbsd mandatory with
> >> it if you want to use lvgl?
> >>
> > With this change in the configuration, the evdev module will be
> > required to compile as it includes the evdev header files if this
> > option is set, just like in the case of fbdev. The build options still
> > remain same, so we can add --no-drivers and these files won't be
> > touched during the build. If it needs to be further broken down in
> > such a manner that the fbdev is required but not evdev, then I think
> > we can keep this option enabled and check it during waf configuration
> > if evdev is available. If not, we can skill building the evdev files.
> >
> > Do you think such checking would be necessary or would it be
> > sufficient to have the --no-drivers option? I'll work on it
> > accordingly if more options are required.
>
> First: --no-drivers should be enough for now.
>
> On the long term, I think we should slowly move to a better
> configurability. I'm not sure yet how that could look. The method that
> we use to build littlevgl is a bit limiting. The library has a quite
> fixed configuration (the lv_conf.h). For example if you want to use a
> different color depth than 16 bit, you have to adapt the build. If you
> want to use a different maximum resulution, you have to adapt the build.
>
> That's quite limiting. Either the settings in our repository match your
> requirements or you have to build the library yourself. It would be
> great if we could get a bit of more flexibility. Of course some of these
> points can't really be changed easily. It's just how littlevgl works.
>
> But it's the reason that I'm a bit careful when we add something that
> adds further restrictions. We maybe end up with a really nice build
> system that can build the library for exactly one demo application.
>

Since the lvgl is too dependent on the conf files, I was thinking of
an approach to generate the whole conf file according to the input
from the user. There will be default values but the user can change it
when prompted about it during the configuration. Or the user can just
choose to press enter to all the prompts and a file with default
configuration will be created.

BTW, I posted about an example app based on these patches here:
https://lists.rtems.org/pipermail/devel/2020-June/060054.html
Please have a look (especially the video ;) ) and review the app when
you have time :)


Best regards,

Vijay
> The drivers part is a quite separate and less critical one. So
> --no-drivers should be OK for that. So feel free to go on with it.
>
> Best regards
>
> Christian
>
> >
> > Thanks for the review.
> >
> > Best regards,
> > Vijay
> >> Best regards
> >>
> >> Christian
> >>
> >>> +
> >>> +#if USE_EVDEV || USE_BSD_EVDEV
> >>>  #  define EVDEV_NAME   "/dev/input/event0"/*You can use the 
> >>> "evtest" Linux tool to get the list of devices and test them*/
> >>>  #  define EVDEV_SWAP_AXES 0   /*Swap the x and y 
> >>> axes of the touchscreen*/
> >>>
> >>>
> >>
> >> --
> >> 
> >> embedded brains GmbH
> >> Herr Christian Mauderer
> >> Dornierstr. 4
> >> D-82178 Puchheim
> >> Germany
> >> email: christian.maude...@embedded-brains.de
> >> Phone: +49-89-18 94 741 - 18
> >> Fax:   +49-89-18 94 741 - 08
> >> PGP: Public key available on request.
> >>
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> 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: Setting up the TTBR0 and TTBR1 register for thread stack protection in ARMv7-A MMU

[Hesham Almatary]

Hello Utkarsh,

TTBR1 is there primarily for UNIX-like kernels to be re-mapped at very
high addresses and user space can use TTBR0. In the case of RTEMS, we
don't have that user vs kernel separation. Furthermore, using TTBR1
won't allow us to do 1:1 fixed mappings.

Could you give more details why having different page sizes would be
an issue? You would normally have multi-level page tables for more
fine-grained page sizes.

On Thu, 4 Jun 2020 at 11:44, Utkarsh Rai  wrote:
>
> Hello,
>
> Section B3.3.3 of the ARMv7-A Reference manual says that we can have TTBR0 
> and 1 split up the address space into two parts, where each register has the 
> address of the translation table base
> of the divided address space.
> One of the ways to simplify the implementation of thread-stack protection in 
> ARMv7-A MMU can be, to have the global statically allocated sections being 
> pointed by the TTBR1 register and the work-space area being pointed out by 
> the TTBR0 register. This way during context switch we would only have to 
> change the TTBR0 register, this would also simplify the implementation as we 
> won't have to worry about addresses of different page sizes being pointed by 
> the same translation-table base.
> In the current implementation, TTB is put in TTBR0, and TTBR1 is not used.
> Is the above-suggested implementation feasible?
>
> Regards,
> Utkarsh



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

Re: Setting up the TTBR0 and TTBR1 register for thread stack protection in ARMv7-A MMU

[Gedare Bloom]

On Fri, Jun 5, 2020 at 6:49 AM Hesham Almatary  wrote:
>
> Hello Utkarsh,
>
> TTBR1 is there primarily for UNIX-like kernels to be re-mapped at very
> high addresses and user space can use TTBR0. In the case of RTEMS, we
> don't have that user vs kernel separation. Furthermore, using TTBR1
> won't allow us to do 1:1 fixed mappings.
>
> Could you give more details why having different page sizes would be
> an issue? You would normally have multi-level page tables for more
> fine-grained page sizes.
+1

>
> On Thu, 4 Jun 2020 at 11:44, Utkarsh Rai  wrote:
> >
> > Hello,
> >
> > Section B3.3.3 of the ARMv7-A Reference manual says that we can have TTBR0 
> > and 1 split up the address space into two parts, where each register has 
> > the address of the translation table base
> > of the divided address space.
> > One of the ways to simplify the implementation of thread-stack protection 
> > in ARMv7-A MMU can be, to have the global statically allocated sections 
> > being pointed by the TTBR1 register and the work-space area being pointed 
> > out by the TTBR0 register. This way during context switch we would only 
> > have to change the TTBR0 register, this would also simplify the 
> > implementation as we won't have to worry about addresses of different page 
> > sizes being pointed by the same translation-table base.
> > In the current implementation, TTB is put in TTBR0, and TTBR1 is not used.

To clear a possible confusion, you can't have multiple workspaces.
That is the dynamic memory region (e.g., program heap) used by RTEMS
to manage object allocations.

> > Is the above-suggested implementation feasible?
> >
> > Regards,
> > Utkarsh
>
>
>
> --
> Hesham
> ___
> 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: Setting up the TTBR0 and TTBR1 register for thread stack protection in ARMv7-A MMU

[Utkarsh Rai]

On Fri, Jun 5, 2020 at 6:19 PM Hesham Almatary 
wrote:

> Hello Utkarsh,
>
> TTBR1 is there primarily for UNIX-like kernels to be re-mapped at very
> high addresses and user space can use TTBR0. In the case of RTEMS, we
> don't have that user vs kernel separation. Furthermore, using TTBR1
> won't allow us to do 1:1 fixed mappings.
>
>
I agree, sorry, after looking around a bit more I realized some of the
above limitations.


> Could you give more details why having different page sizes would be
> an issue? You would normally have multi-level page tables for more
> fine-grained page sizes.


No this will not be an issue, we can set the bits[1:0]  of the table-entry
to account for the levels of page tables. I was thinking about ways to
simplify the implementation of stack allocation, but doing this is
definitely not feasible.


>
On Thu, 4 Jun 2020 at 11:44, Utkarsh Rai  wrote:
> >
> > Hello,
> >
> > Section B3.3.3 of the ARMv7-A Reference manual says that we can have
> TTBR0 and 1 split up the address space into two parts, where each register
> has the address of the translation table base
> > of the divided address space.
> > One of the ways to simplify the implementation of thread-stack
> protection in ARMv7-A MMU can be, to have the global statically allocated
> sections being pointed by the TTBR1 register and the work-space area being
> pointed out by the TTBR0 register. This way during context switch we would
> only have to change the TTBR0 register, this would also simplify the
> implementation as we won't have to worry about addresses of different page
> sizes being pointed by the same translation-table base.
> > In the current implementation, TTB is put in TTBR0, and TTBR1 is not
> used.
> > Is the above-suggested implementation feasible?
> >
> > Regards,
> > Utkarsh
>
>
>
> --
> Hesham
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: LVGL applications with mouse

[Christian Mauderer]

Hello Vijay,

On 04/06/2020 21:36, Vijay Kumar Banerjee wrote:
> Hi!
> 
> I had been looking for an opportunity to do this for a long time and I'm
> excited to post that LVGL apps on RTEMS can now use input devices
> through the evdev interface!

Sounds like a nice feature.

> 
> I prepared some BSD evdev patches for lvgl repository and managed to get
> them merged upstream. The patchset that I recently send to devel for
> libbsd[1] and rtems-littlevgl[2], updates the rtems-libbsd and
> rtems-littlevgl repository to adapt to the latest lvgl changes upstream
> and adds the evdev support to rtems-littlevgl.
> 
> I wrote an example lvgl application that uses the mouse, connected
> through USB port of Beaglebone black. The example application uses the
> RTEMS logo, which makes it a bit heavier patch for the devel. I have
> posted the commit on my github fork [3] and would really appreciate it
> if someone can review and approve it to merge upstream.

Although most likely touch screens are more common in embedded systems,
it's a good example. A lot of touchscreens should work via evdev too.

Regarding the logo size: Also an RTEMS logo is a nice idea, maybe
something smaller would be better to avoid that big file in the repo?
Depending on how you generated the image: Maybe some run length encoding
could reduce the size too (for example GIMP offers an option for that
when exporting images to C sources).

> 
> Finally, please have a look at this very short video that shows the
> example application running. It uses many features of lvgl, including
> image, button, and input:
> https://blog.thelunatic.dev/assets/video/lvgl_rtems_logo.mp4

Looks great.

Best regards

Christian

> 
> We can now make full-fledged GUI applications with LVGL on RTEMS. :)
> 
> [1]: https://lists.rtems.org/pipermail/devel/2020-June/060049.html
> [2]: https://lists.rtems.org/pipermail/devel/2020-June/060050.html
> [3]:
> https://github.com/thelunatic/rtems-examples/commit/c526d3c06a69591dc36e62af32728c51012ea6c1
> 
> Thanks!
> Vijay
> 
> ___
> 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 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

[Mritunjay Sharma]

Thank you so much Heinz for such a detailed response.
It really helped me a lot.

As advised by you and Heinz, I changed the source to
https://github.com/mritunjaysharma394/ptpd/archive/master.zip
with suggested changes. However, I have encountered few bugs again related
to autoreconf.
It looks somewhat like this:

+ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: creating directory build-aux
autoreconf: configure.ac: not using Libtool
autoreconf: running: /home/mritunjay/development/rtems/5/bin/autoconf
configure.ac:28: error: possibly undefined macro: AC_PROG_LIBTOOL
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
autoreconf: /home/mritunjay/development/rtems/5/bin/autoconf failed with
exit status: 1
shell cmd failed: /bin/sh -ex
 
/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
error: building ptpd-master-arm-rtems5-1

I have attached the error report as well and changes in cfg files can be
found here:
https://github.com/mritunjaysharma394/rtems-source-builder/commit/6b6bb2b3bd778ebe56e9a1bf3aec1747b078fd39

Thanks,
Mritunjay


On Fri, Jun 5, 2020 at 2:53 AM Gedare Bloom  wrote:

> On Thu, Jun 4, 2020 at 1:38 PM junkes  wrote:
> >
> > Hallo Mritunjay,
> >
> > You can't just take the github ptpd sources and make them work in RTEMS.
> You have to make some configuration
> > and sources changes before you can build the with the rsb.
> >
> > Some things like the sys/cpuset.h seems not to be fully compatible yet
> and so the configure simply makes
> > "wrong" decisions. E.g. defines HAVE_SYS_CPUSET_H = 1 as sys/cpuset.h
> exists.I played a little bit with it and reset
> > the definition in ptpd-master/src/ptpd.h  (quick and dirty) and could
> reduce the error messages because there is a query for
> > this variable in the code (src/dep/sys.c):
> >
> > in ptpd.h after the include of the created configs :
> >
> > ...
> > #ifdef HAVE_CONFIG_H
> > # include 
> > #endif /* HAVE_CONFIG_H */
> >
> > #undef HAVE_NTP_GETTIME
> > #undef HAVE_SYS_CPUSET_H
> >
> > #ifdef linux
> > ...
> >
> > in src/dep/sys.c
> >
> > ...
> > #ifdef HAVE_SYS_CPUSET_H
> >cpuset_t mask;
> >CPU_ZERO(&mask);
> >if(cpu >= 0) {
> >CPU_SET(cpu,&mask);
> >} else {
> >int i;
> >for(i = 0;  i < CPU_SETSIZE; i++) {
> >CPU_SET(i, &mask);
> >}
> >}
> >return(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
> >  -1, sizeof(mask), &mask));
> > #endif /* HAVE_SYS_CPUSET_H */
> >
> > In src/dep/constants_dep.h  one can find:
> >
> > * platform dependent */
> >
> > #if !defined(linux) && !defined(__NetBSD__) && !defined(__FreeBSD__) && \
> > !defined(__APPLE__) && !defined(__OpenBSD__) && !defined(__sun) &&
> !defined(__QNXNTO__)
> > #error PTPD hasn't been ported to this OS - should be possible \
> > if it's POSIX compatible, if you succeed, report it to
> ptpd-de...@sourceforge.net
> > #endif
> >
> > here I added "&& !defined(__rtems__)
> >
> > and here:
> > ...
> > #if defined(__NetBSD__) || defined(__FreeBSD__) || defined(__APPLE__) ||
> defined(__OpenBSD__) || defined(__sun) || defined(__QNXNTO__) ||
> defined(__rtems__)
> > # include 
> > # include 
> > #ifdef HAVE_SYS_SOCKIO_H
> > #include 
> > #endif /* HAVE_SYS_SOCKIO_H */
> > # include 
> > # include 
> > # include 
> > # include 
> > #ifdef HAVE_NET_IF_ETHER_H
> > #  include 
> > ...
> >
> > and so on... You'd have to bite through it once and then you will surely
> get it compiled.
> >
> Great start Heinz! Mritunjay, I think this definitely the way forward.
> Later, you might try to circle back and fix the hacks in nicer ways by
> learning how to make the autoconf stuff work correctly, and contribute
> those fixes back upstream to ptpd project.
>
> > HTH Heinz
> >
> >
> >
> > On 2020-06-04 20:29, Mritunjay Sharma wrote:
> >
> >
> >
> > On Thu, Jun 4, 2020 at 11:07 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >
> > On 04/06/2020 16:22, Gedare Bloom wrote:
> >
> > >>> In the github version this code is conditional on sys/cpuset.h being
> present.
> > >>>
> > > Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
> > > definitions though. Probably either:
> > > 1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
> > > would mean adding cpuset_setaffinity support in rtems, I guess.
> > > 2. Figure out how to disable the conditional code using the
> > > cpuset_setaffinity function.
> > The  is already as compatible as possible to glibc and
> > FreeBSD. There is always room for improvement, however, in this area it
> > will be difficult.
> >
> >
> > Please it would be kind of you all to guide on what is the best thing I
> can do next. It is looking

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

[Gedare Bloom]

Is this the same error Heinz said he got every other time? Try it
twice, see what happens...

On Fri, Jun 5, 2020 at 5:31 PM Mritunjay Sharma
 wrote:
>
>
> Thank you so much Heinz for such a detailed response.
> It really helped me a lot.
>
> As advised by you and Heinz, I changed the source to 
> https://github.com/mritunjaysharma394/ptpd/archive/master.zip
> with suggested changes. However, I have encountered few bugs again related to 
> autoreconf.
> It looks somewhat like this:
>
> + autoreconf -i -v
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal -I m4
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: creating directory build-aux
> autoreconf: configure.ac: not using Libtool
> autoreconf: running: /home/mritunjay/development/rtems/5/bin/autoconf
> configure.ac:28: error: possibly undefined macro: AC_PROG_LIBTOOL
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> autoreconf: /home/mritunjay/development/rtems/5/bin/autoconf failed with exit 
> status: 1
> shell cmd failed: /bin/sh -ex  
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
> error: building ptpd-master-arm-rtems5-1
>
> I have attached the error report as well and changes in cfg files can be 
> found here:
> https://github.com/mritunjaysharma394/rtems-source-builder/commit/6b6bb2b3bd778ebe56e9a1bf3aec1747b078fd39
>
> Thanks,
> Mritunjay
>
>
> On Fri, Jun 5, 2020 at 2:53 AM Gedare Bloom  wrote:
>>
>> On Thu, Jun 4, 2020 at 1:38 PM junkes  wrote:
>> >
>> > Hallo Mritunjay,
>> >
>> > You can't just take the github ptpd sources and make them work in RTEMS. 
>> > You have to make some configuration
>> > and sources changes before you can build the with the rsb.
>> >
>> > Some things like the sys/cpuset.h seems not to be fully compatible yet and 
>> > so the configure simply makes
>> > "wrong" decisions. E.g. defines HAVE_SYS_CPUSET_H = 1 as sys/cpuset.h 
>> > exists.I played a little bit with it and reset
>> > the definition in ptpd-master/src/ptpd.h  (quick and dirty) and could 
>> > reduce the error messages because there is a query for
>> > this variable in the code (src/dep/sys.c):
>> >
>> > in ptpd.h after the include of the created configs :
>> >
>> > ...
>> > #ifdef HAVE_CONFIG_H
>> > # include 
>> > #endif /* HAVE_CONFIG_H */
>> >
>> > #undef HAVE_NTP_GETTIME
>> > #undef HAVE_SYS_CPUSET_H
>> >
>> > #ifdef linux
>> > ...
>> >
>> > in src/dep/sys.c
>> >
>> > ...
>> > #ifdef HAVE_SYS_CPUSET_H
>> >cpuset_t mask;
>> >CPU_ZERO(&mask);
>> >if(cpu >= 0) {
>> >CPU_SET(cpu,&mask);
>> >} else {
>> >int i;
>> >for(i = 0;  i < CPU_SETSIZE; i++) {
>> >CPU_SET(i, &mask);
>> >}
>> >}
>> >return(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>> >  -1, sizeof(mask), &mask));
>> > #endif /* HAVE_SYS_CPUSET_H */
>> >
>> > In src/dep/constants_dep.h  one can find:
>> >
>> > * platform dependent */
>> >
>> > #if !defined(linux) && !defined(__NetBSD__) && !defined(__FreeBSD__) && \
>> > !defined(__APPLE__) && !defined(__OpenBSD__) && !defined(__sun) && 
>> > !defined(__QNXNTO__)
>> > #error PTPD hasn't been ported to this OS - should be possible \
>> > if it's POSIX compatible, if you succeed, report it to 
>> > ptpd-de...@sourceforge.net
>> > #endif
>> >
>> > here I added "&& !defined(__rtems__)
>> >
>> > and here:
>> > ...
>> > #if defined(__NetBSD__) || defined(__FreeBSD__) || defined(__APPLE__) || 
>> > defined(__OpenBSD__) || defined(__sun) || defined(__QNXNTO__) || 
>> > defined(__rtems__)
>> > # include 
>> > # include 
>> > #ifdef HAVE_SYS_SOCKIO_H
>> > #include 
>> > #endif /* HAVE_SYS_SOCKIO_H */
>> > # include 
>> > # include 
>> > # include 
>> > # include 
>> > #ifdef HAVE_NET_IF_ETHER_H
>> > #  include 
>> > ...
>> >
>> > and so on... You'd have to bite through it once and then you will surely 
>> > get it compiled.
>> >
>> Great start Heinz! Mritunjay, I think this definitely the way forward.
>> Later, you might try to circle back and fix the hacks in nicer ways by
>> learning how to make the autoconf stuff work correctly, and contribute
>> those fixes back upstream to ptpd project.
>>
>> > HTH Heinz
>> >
>> >
>> >
>> > On 2020-06-04 20:29, Mritunjay Sharma wrote:
>> >
>> >
>> >
>> > On Thu, Jun 4, 2020 at 11:07 PM Sebastian Huber 
>> >  wrote:
>> >
>> > On 04/06/2020 16:22, Gedare Bloom wrote:
>> >
>> > >>> In the github version this code is conditional on sys/cpuset.h being 
>> > >>> present.
>> > >>>
>> > > Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
>> > > definitions though. Probably either:
>> > > 1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
>> > > would mean adding cpuset_setaffinity support in rtems, I guess.
>> > > 2. Figure out how to disable the c

[PATCH] fenv aarch64 support

[Eshan dhawan]

The implementation files are taken forn FreeBSD.

All the Auto-Generated files have been removed.

The Patch is tested against RSB but there is no BSP
for aarch64 so running testsuite is not possible.

Signed-off-by: Eshan dhawan 
---
 newlib/libc/machine/aarch64/machine/fenv-fp.h | 156 ++
 newlib/libc/machine/aarch64/sys/fenv.h| 120 ++
 newlib/libm/machine/aarch64/Makefile.am   |  14 +-
 newlib/libm/machine/aarch64/feclearexcept.c   |   7 +
 newlib/libm/machine/aarch64/fegetenv.c|   7 +
 newlib/libm/machine/aarch64/fegetexceptflag.c |   7 +
 newlib/libm/machine/aarch64/fegetround.c  |   7 +
 newlib/libm/machine/aarch64/feholdexcept.c|   7 +
 newlib/libm/machine/aarch64/fenv.c|  57 +++
 newlib/libm/machine/aarch64/feraiseexcept.c   |   7 +
 newlib/libm/machine/aarch64/fesetenv.c|   7 +
 newlib/libm/machine/aarch64/fesetexceptflag.c |   7 +
 newlib/libm/machine/aarch64/fesetround.c  |   7 +
 newlib/libm/machine/aarch64/fetestexcept.c|   7 +
 newlib/libm/machine/aarch64/feupdateenv.c |   7 +
 15 files changed, 423 insertions(+), 1 deletion(-)
 create mode 100644 newlib/libc/machine/aarch64/machine/fenv-fp.h
 create mode 100644 newlib/libc/machine/aarch64/sys/fenv.h
 create mode 100644 newlib/libm/machine/aarch64/feclearexcept.c
 create mode 100644 newlib/libm/machine/aarch64/fegetenv.c
 create mode 100644 newlib/libm/machine/aarch64/fegetexceptflag.c
 create mode 100644 newlib/libm/machine/aarch64/fegetround.c
 create mode 100644 newlib/libm/machine/aarch64/feholdexcept.c
 create mode 100644 newlib/libm/machine/aarch64/fenv.c
 create mode 100644 newlib/libm/machine/aarch64/feraiseexcept.c
 create mode 100644 newlib/libm/machine/aarch64/fesetenv.c
 create mode 100644 newlib/libm/machine/aarch64/fesetexceptflag.c
 create mode 100644 newlib/libm/machine/aarch64/fesetround.c
 create mode 100644 newlib/libm/machine/aarch64/fetestexcept.c
 create mode 100644 newlib/libm/machine/aarch64/feupdateenv.c

diff --git a/newlib/libc/machine/aarch64/machine/fenv-fp.h 
b/newlib/libc/machine/aarch64/machine/fenv-fp.h
new file mode 100644
index 0..d8ec3fc76
--- /dev/null
+++ b/newlib/libc/machine/aarch64/machine/fenv-fp.h
@@ -0,0 +1,156 @@
+/*-
+ * Copyright (c) 2004-2005 David Schultz 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+
+__fenv_static __inline int
+feclearexcept(int __excepts)
+{
+   fexcept_t __r;
+
+   __mrs_fpsr(__r);
+   __r &= ~__excepts;
+   __msr_fpsr(__r);
+   return (0);
+}
+
+__fenv_static inline int
+fegetexceptflag(fexcept_t *__flagp, int __excepts)
+{
+   fexcept_t __r;
+
+   __mrs_fpsr(__r);
+   *__flagp = __r & __excepts;
+   return (0);
+}
+
+__fenv_static inline int
+fesetexceptflag(const fexcept_t *__flagp, int __excepts)
+{
+   fexcept_t __r;
+
+   __mrs_fpsr(__r);
+   __r &= ~__excepts;
+   __r |= *__flagp & __excepts;
+   __msr_fpsr(__r);
+   return (0);
+}
+
+__fenv_static inline int
+feraiseexcept(int __excepts)
+{
+   fexcept_t __r;
+
+   __mrs_fpsr(__r);
+   __r |= __excepts;
+   __msr_fpsr(__r);
+   return (0);
+}
+
+__fenv_static inline int
+fetestexcept(int __excepts)
+{
+   fexcept_t __r;
+
+   __mrs_fpsr(__r);
+   return (__r & __excepts);
+}
+
+__fenv_static inline int
+fegetround(void)
+{
+   fenv_t __r;
+
+   __mrs_fpcr(__r);
+   return ((__r >> _ROUND_SHIFT) & _ROUND_MASK);
+}
+
+__fenv_static inline int
+fesetround(int __round)
+{
+   fenv_t __r;
+
+   if (__round & ~_ROUND_MASK)
+   return (-1);
+   __mrs_fpcr(__r);
+   __r &= ~(_ROUND_MASK << _ROUND_SHIFT);
+