Re: [GSoC 2020]: Weekly thread update

On Sat, Jul 18, 2020 at 2:02 PM Mritunjay Sharma wrote: > > [UPDATE]: Thank you so much Heinz, with commit > `3afec267ab08568ea454789e562450b00feea5c0`v > I was able to successfully built EPICS7 with RTEMS5 for pc-386 and pc-386 > qemu both. > Great. Is this with --enable-networking? Is libbsd

Re: [GSoC 2020]: Weekly thread update

[UPDATE]: Thank you so much Heinz, with commit ` 3afec267ab08568ea454789e562450b00feea5c0`v I was able to successfully built EPICS7 with RTEMS5 for pc-386 and pc-386 qemu both. As advised, should I begin writing RSB recipe now for RTEMS5? What can be the next steps? Please advise and also guide o

[PATCH v4] Changed ARM fenv support and remodeled it similar to RISCV

Removed all the Extra files Added soft fp support similar to RISCV Has fenv stub implementation. Signed-off-by: Eshan dhawan --- newlib/libc/machine/arm/machine/fenv-mangle.h | 53 --- .../libc/machine/arm/machine/fenv-softfloat.h | 187 -- newlib/libc/machine/arm/machine/fenv-vfp.h

Re: [GSoC 2020]: Weekly thread update

Thank you so much, I am trying and reverting soon. On Sat, Jul 18, 2020 at 10:45 PM Heinz Junkes wrote: > Mritunjay, > can you try to use the commit 3afec267ab08568ea454789e562450b00feea5c0 > Dated 25.9. 2019 > > From Heinz > > On 17.07.2020, at 20:23, Mritunjay Sharma > wrote: > > > > On Fri,

Re: [GSoC 2020]: Weekly thread update

Mritunjay, can you try to use the commit 3afec267ab08568ea454789e562450b00feea5c0 Dated 25.9. 2019 From Heinz > On 17.07.2020, at 20:23, Mritunjay Sharma > wrote: > > > >> On Fri, Jul 17, 2020 at 12:53 PM Heinz Junkes >> wrote: >> You are right. I was not aware of that the dhcpcd stuff is

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

On 18/07/2020 18:46, Eshan Dhawan wrote: On Sat, Jul 18, 2020 at 9:32 PM Gedare Bloom > wrote: On Sat, Jul 18, 2020 at 9:39 AM Eshan Dhawan mailto:eshandhawa...@gmail.com>> wrote: > > > > On 18-Jul-2020, at 8:51 PM, Sebastian Huber mailto:seba

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

On Sat, Jul 18, 2020 at 9:32 PM Gedare Bloom wrote: > On Sat, Jul 18, 2020 at 9:39 AM Eshan Dhawan > wrote: > > > > > > > On 18-Jul-2020, at 8:51 PM, Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > > > > > > On 18/07/2020 17:17, Eshan Dhawan wrote: > > > > > > On 18-Jul-202

Re: GSoC: Correct placement and naming of memory protection APIs

On Sat, Jul 18, 2020 at 3:55 AM Utkarsh Rai wrote: > > > > On Sat, Jul 18, 2020 at 1:21 PM Hesham Almatary > wrote: >> >> We have already discussed and done that during my 2013 GSoC. Have a >> look at [1, 2] and their calls. >> >> [1] >> https://github.com/heshamelmatary/rtems-gsoc2013/blob/low

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

On Sat, Jul 18, 2020 at 9:39 AM Eshan Dhawan wrote: > > > > On 18-Jul-2020, at 8:51 PM, Sebastian Huber > > wrote: > > > > On 18/07/2020 17:17, Eshan Dhawan wrote: > > > > On 18-Jul-2020, at 4:52 PM, Sebastian Huber > > wrote: > Hello Eshan, > you produce a lot of extra wor

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

On 18/07/2020 17:39, Eshan Dhawan wrote: Why is x86_64mentioned in the commit message? On the mailing list it was discussed to use RISC-V as the model. Please improve the commit message in general. It should reflect all the problems discussed on the mailing list and how the commit addresses t

Re: A question about rtems license

On Sat, Jul 18, 2020 at 9:20 AM Christian Mauderer wrote: > > Hello, > > note that I'm not a lawyer. I can only provide my personal opinion > regarding that topic. Depending of the legal system of your country a > lawyer might has a different point of view. I'm also only a small part > of the proj

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

> On 18-Jul-2020, at 8:51 PM, Sebastian Huber > wrote: > > On 18/07/2020 17:17, Eshan Dhawan wrote: > > On 18-Jul-2020, at 4:52 PM, Sebastian Huber > wrote: Hello Eshan, you produce a lot of extra work for me. Your patch applies now. But it didn't build: make[9

Re: Need help in understanding some of the existing code in RTEMS

On Fri, Jul 17, 2020 at 2:22 AM Richi Dubey wrote: >> >> >> > Scheduler_Node *nodes; >> > } Thread_Scheduler_control; >> > >> > Why do we have a Scheduler_Node *nodes? What does it indicate? Since the >> > pointer can point to a single value, why is it being called nodes? >> > >> See cpukit/sco

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

On 18/07/2020 17:17, Eshan Dhawan wrote: On 18-Jul-2020, at 4:52 PM, Sebastian Huber wrote: Hello Eshan, you produce a lot of extra work for me. Your patch applies now. But it didn't build: make[9]: *** No rule to make target 'fenv-vfp.c', needed by 'lib_a-fenv-vfp.o'. Stop. make[9]: **

Re: A question about rtems license

Hello, note that I'm not a lawyer. I can only provide my personal opinion regarding that topic. Depending of the legal system of your country a lawyer might has a different point of view. I'm also only a small part of the project and can't speak for all persons involved. As far as I understand y

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

> On 18-Jul-2020, at 4:52 PM, Sebastian Huber > wrote: > > Hello Eshan, > > you produce a lot of extra work for me. Your patch applies now. But it didn't > build: > > make[9]: *** No rule to make target 'fenv-vfp.c', needed by > 'lib_a-fenv-vfp.o'. Stop. > make[9]: *** Waiting for unfinis

Re: Thread 2: Need help in understanding exisiting RTEMS code

This information helps. Thank you. On Fri, Jul 17, 2020 at 6:31 PM Sebastian Huber wrote: > > On 17/07/2020 14:22, Richi Dubey wrote: > > > I found the line in the documentation: "Since the processor assignment > > is independent of the thread priority the processor indices may move > > from one

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

Hello Eshan, you produce a lot of extra work for me. Your patch applies now. But it didn't build: make[9]: *** No rule to make target 'fenv-vfp.c', needed by 'lib_a-fenv-vfp.o'.  Stop. make[9]: *** Waiting for unfinished jobs make[9]: Leaving directory '/build/git-build/b-gcc-10.1.0-arm

Re: GSoC: Correct placement and naming of memory protection APIs

On Sat, Jul 18, 2020 at 1:21 PM Hesham Almatary < hesham.almat...@cl.cam.ac.uk> wrote: > We have already discussed and done that during my 2013 GSoC. Have a > look at [1, 2] and their calls. > > [1] > https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/

Re: GSoC: Correct placement and naming of memory protection APIs

We have already discussed and done that during my 2013 GSoC. Have a look at [1, 2] and their calls. [1] https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mmimpl.h [2] https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit