Re: Cortex-M floating point (Was: RTEMS 6 branching)

2024-05-01 Thread Chris Johns
On 2/5/2024 7:18 am, Cedric Berger wrote:
> Hello,
> 
> On 25.04.2024 02:16, Chris Johns wrote:
>> I know I am getting ahead of myself but once we have GiLab running and you 
>> have
>> a patch you would like merged please make a merge request.
> 
> Done:
> 
> https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/10
> 
> It worked really well.
> 

Yay and thanks for letting us know.

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


Re: Cortex-M floating point (Was: RTEMS 6 branching)

2024-05-01 Thread Cedric Berger

Hello,

On 25.04.2024 02:16, Chris Johns wrote:

I know I am getting ahead of myself but once we have GiLab running and you have
a patch you would like merged please make a merge request.


Done:

https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/10

It worked really well.

Cedric

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

Re: Cortex-M floating point (Was: RTEMS 6 branching)

2024-04-24 Thread Sebastian Huber

On 24.04.24 14:37, Cedric Berger wrote:

Hello Sebastian,

On 23.04.2024 19:56, Sebastian Huber wrote:

1. Are all the things need for the release resolved? Tickets reviewed?

It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
Cortex-M floating point issue is not yet fixed in the RTEMS master.


Do you have any feedback on the two patches that I posted on the ticket, 
which seems to fix the issue?


It would be great if you could check the patch at the end of this mail:

https://lists.rtems.org/pipermail/devel/2024-February/077228.html

--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Cortex-M floating point (Was: RTEMS 6 branching)

2024-04-24 Thread Chris Johns
On 24/4/2024 10:37 pm, Cedric Berger wrote:
> Hello Sebastian,
> 
> On 23.04.2024 19:56, Sebastian Huber wrote:
>>> 1. Are all the things need for the release resolved? Tickets reviewed?
>> It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
>> Cortex-M floating point issue is not yet fixed in the RTEMS master.
> 
> Do you have any feedback on the two patches that I posted on the ticket, which
> seems to fix the issue?

Thanks to everyone for responding. It seems clear the 6 branch will happen once
GitLab is launched. Once we launch the 6 milestone can be used with burndown and
burnup charts
(https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)
to track the branch point.

I know I am getting ahead of myself but once we have GiLab running and you have
a patch you would like merged please make a merge request. If there is an issue
please make sure it is on the 6.1 milestone or create one and assign it to the
milestone.

In the meantime Amar and I will take a look at the release notes. We think these
can be based on a ChangeLog report created via the GitLab API. The wrinkle here
is the API needs a key and that of course cannot be exposed in commits.

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


Re: Cortex-M floating point (Was: RTEMS 6 branching)

2024-04-24 Thread Chris Johns
On 24/4/2024 10:37 pm, Cedric Berger wrote:
> Hello Sebastian,
> 
> On 23.04.2024 19:56, Sebastian Huber wrote:
>>> 1. Are all the things need for the release resolved? Tickets reviewed?
>> It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
>> Cortex-M floating point issue is not yet fixed in the RTEMS master.
> 
> Do you have any feedback on the two patches that I posted on the ticket, which
> seems to fix the issue?

Thanks to everyone for responding. It seems clear the 6 branch will happen once
GitLab is launched. Once we launch the 6 milestone can be used with burndown and
burnup charts
(https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)
to track the branch point.

I know I am getting ahead of myself but once we have GiLab running and you have
a patch you would like merged please make a merge request. If there is an issue
please make sure it is on the 6.1 milestone or create one and assign it to the
milestone.

In the meantime Amar and I will take a look at the release notes. We think these
can be based on a ChangeLog report created via the GitLab API. The wrinkle here
is the API needs a key and that of course cannot be exposed in commits.

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