Update #3941.
---
rtems/config/6/rtems-all.bset | 1 -
rtems/config/6/rtems-epiphany.bset | 17 -
rtems/config/7/rtems-all.bset | 1 -
3 files changed, 19 deletions(-)
delete mode 100644 rtems/config/6/rtems-epiphany.bset
diff --git a/rtems/config/6/rtems-all.bset
Due to an unmaintained toolchain (internal errors in GCC, no FSF GDB
integration) the Epiphany architecture was obsoleted in RTEMS 5.1.
Update #3941.
---
bsps/epiphany/epiphany_sim/README | 6 -
bsps/epiphany/epiphany_sim/btimer/btimer.c| 108 ---
Update #3941.
---
config/rtems-bsps-epiphany.ini | 25 -
config/rtems-bsps-tiers.ini| 3 +--
config/rtems-bsps.ini | 3 ---
3 files changed, 1 insertion(+), 30 deletions(-)
delete mode 100644 config/rtems-bsps-epiphany.ini
diff --git
---
cpu-supplement/epiphany.rst | 89 ++---
user/bsps/bsps-epiphany.rst | 11 -
user/bsps/index.rst | 1 -
3 files changed, 4 insertions(+), 97 deletions(-)
delete mode 100644 user/bsps/bsps-epiphany.rst
diff --git a/cpu-supplement/epiphany.rst
On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault wrote:
> I finally have gotten to reviewing Utkarsh's work in GSOC. One item that
> I don't like is that there is a linked list management of the threads that
> have access to the stack.
> I think this access is similar to the file descriptors that
On 3/7/20 9:01 am, Mritunjay Sharma wrote:
> Thank you so much Gedare, I think the problem was with confusion related to
> prefix and source being the same which created a lot of problems.
>
> I just had an offlist discussion with Vijay and he has cleared all my doubts
> and
> the mistakes I
Thank you so much Gedare, I think the problem was with confusion related to
prefix and source being the same which created a lot of problems.
I just had an offlist discussion with Vijay and he has cleared all my
doubts and
the mistakes I was making. The problem as of now seems to be resolved.
I
On Thu, Jul 2, 2020 at 2:52 PM Mritunjay Sharma
wrote:
>
>
>
> On Fri, Jul 3, 2020 at 1:59 AM Vijay Kumar Banerjee wrote:
>>
>> On Fri, Jul 3, 2020 at 1:41 AM Mritunjay Sharma
>> wrote:
>> >
>> >
>> >
>> > On Fri, Jul 3, 2020 at 12:21 AM Vijay Kumar Banerjee
>> > wrote:
>> >>
>> >> On Fri,
---
eng/coding-file-hdr.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eng/coding-file-hdr.rst b/eng/coding-file-hdr.rst
index 6355173..cda631a 100644
--- a/eng/coding-file-hdr.rst
+++ b/eng/coding-file-hdr.rst
@@ -96,7 +96,7 @@ Use the following guidelines and template
This commit move the bsp/fdt.h header to cpukit/include/rtems.
The reason for this is, with inclusion of libfreebsd there are
cases where their is need for bsp_fdt_get(). And with this
header under bsps directory it is not possible to include it
under a cpukit directory.
---
On Fri, Jul 3, 2020 at 1:59 AM Vijay Kumar Banerjee wrote:
> On Fri, Jul 3, 2020 at 1:41 AM Mritunjay Sharma
> wrote:
> >
> >
> >
> > On Fri, Jul 3, 2020 at 12:21 AM Vijay Kumar Banerjee
> wrote:
> >>
> >> On Fri, Jul 3, 2020 at 12:15 AM Mritunjay Sharma
> >> wrote:
> >> >
> >> >
> >> >
> >>
On Fri, Jul 3, 2020 at 1:41 AM Mritunjay Sharma
wrote:
>
>
>
> On Fri, Jul 3, 2020 at 12:21 AM Vijay Kumar Banerjee wrote:
>>
>> On Fri, Jul 3, 2020 at 12:15 AM Mritunjay Sharma
>> wrote:
>> >
>> >
>> >
>> > On Fri, Jul 3, 2020 at 12:10 AM Vijay Kumar Banerjee
>> > wrote:
>> >>
>> >> On Fri,
On Fri, Jul 3, 2020 at 12:21 AM Vijay Kumar Banerjee
wrote:
> On Fri, Jul 3, 2020 at 12:15 AM Mritunjay Sharma
> wrote:
> >
> >
> >
> > On Fri, Jul 3, 2020 at 12:10 AM Vijay Kumar Banerjee
> wrote:
> >>
> >> On Fri, Jul 3, 2020 at 12:00 AM Mritunjay Sharma
> >> wrote:
> >> >
> >> > I guess
I finally have gotten to reviewing Utkarsh's work in GSOC. One item that I
don't like is that there is a linked list management of the threads that have
access to the stack.
I think this access is similar to the file descriptors that are blocked in a
select call. On a given architecture I
On Fri, Jul 3, 2020 at 12:15 AM Mritunjay Sharma
wrote:
>
>
>
> On Fri, Jul 3, 2020 at 12:10 AM Vijay Kumar Banerjee wrote:
>>
>> On Fri, Jul 3, 2020 at 12:00 AM Mritunjay Sharma
>> wrote:
>> >
>> > I guess the problem can be with my using 'sudo' here
>> > but without using sudo and directly
On Fri, Jul 3, 2020 at 12:10 AM Vijay Kumar Banerjee
wrote:
> On Fri, Jul 3, 2020 at 12:00 AM Mritunjay Sharma
> wrote:
> >
> > I guess the problem can be with my using 'sudo' here
> > but without using sudo and directly using 'make install',
> > the process stops all the more early with the
On Fri, Jul 3, 2020 at 12:00 AM Mritunjay Sharma
wrote:
>
> I guess the problem can be with my using 'sudo' here
> but without using sudo and directly using 'make install',
> the process stops all the more early with the following error:
>
Please try `sudo chmod +x
I guess the problem can be with my using 'sudo' here
but without using sudo and directly using 'make install',
the process stops all the more early with the following error:
"Making install in make
make[1]: Entering directory
'/home/mritunjay/development/rtems_dev/rtems-4.10.2/pc-386/make'
Hello Heinz and everyone,
Thank you so much, using RTEMS RSB for 4.10 really helped me a lot and
saved a lot of time.
Though in all this it was a good learning experience for how to build the
compiler
tools manually too :-)
The make was successful this time and the previous error was resolved
On Thu, Jul 2, 2020 at 11:25 AM Gedare Bloom wrote:
> On Thu, Jul 2, 2020 at 9:48 AM Sebastian Huber
> wrote:
> >
> > On 02/07/2020 09:56, Chris Johns wrote:
> >
> > > On 2/7/20 4:15 am, Sebastian Huber wrote:
> > >> Module: rtems-source-builder
> > >> Branch:master
> > >> Commit:
On Thu, Jul 2, 2020 at 9:48 AM Sebastian Huber
wrote:
>
> On 02/07/2020 09:56, Chris Johns wrote:
>
> > On 2/7/20 4:15 am, Sebastian Huber wrote:
> >> Module: rtems-source-builder
> >> Branch:master
> >> Commit:abe5d1b2fe9ec264d366b876c1387d7f85aaacd6
> >> Changeset:
> >>
On 02/07/2020 09:56, Chris Johns wrote:
On 2/7/20 4:15 am, Sebastian Huber wrote:
Module: rtems-source-builder
Branch: master
Commit: abe5d1b2fe9ec264d366b876c1387d7f85aaacd6
Changeset:
http://git.rtems.org/rtems-source-builder/commit/?id=abe5d1b2fe9ec264d366b876c1387d7f85aaacd6
Hello,
when answering some questions for Niteeshs GSoC project I noted that the
beagleboardorig and beagleboardxm BSPs are really in no good shape.
Since quite a long time only the beaglebone has been maintained. I think
that only very basic stuff will work on the beagleboard if it works at all.
Hello,
This is a follow-up message since activity on this thread has stopped a
couple of days ago.
Thanks,
Niteesh.
On Tue, Jun 30, 2020 at 1:49 AM Niteesh G. S. wrote:
> On Mon, Jun 29, 2020 at 8:59 PM Gedare Bloom wrote:
>
>> On Mon, Jun 29, 2020 at 9:14 AM Niteesh G. S.
>> wrote:
>> >
>>
On Thu, Jul 2, 2020 at 2:56 AM Chris Johns wrote:
> On 2/7/20 4:15 am, Sebastian Huber wrote:
> > Module:rtems-source-builder
> > Branch:master
> > Commit:abe5d1b2fe9ec264d366b876c1387d7f85aaacd6
> > Changeset:
>
Will keep this in mind. Thanks.
On Thu, Jul 2, 2020 at 4:05 PM Jiri Gaisler wrote:
> Note that single-stepping of smp code at instruction-level might affect
> the timing of the execution. During single-stepping, only one core is
> advanced while the others stay halted. If you are trying to
Note that single-stepping of smp code at instruction-level might affect the
timing of the execution. During single-stepping, only one core is advanced
while the others stay halted. If you are trying to catch a race condition then
the timing impact might change the program behavior. Shorter
On 2/7/20 12:22 am, Sebastian Huber wrote:
On 01/07/2020 11:30, Sebastian Huber wrote:
Hello,
the GDB error is:
https://sourceware.org/pipermail/gdb/2020-July/048772.html
This -fno-common default in GCC 10 can be also an issue for some RTEMS
BSPs.
This seems to be a powerpc-specific
Yeah, this makes a lot of sense.
Mr. Huber also told me a similar story about qemu using -O0 optimizations
which are easier to debug.
Thank you.
On Wed, Jul 1, 2020 at 8:03 PM Gedare Bloom wrote:
> On Wed, Jul 1, 2020 at 5:32 AM Richi Dubey wrote:
> >
> > Dear Dr. Gaisler,
> >
> > There's
On 2/7/20 4:15 am, Sebastian Huber wrote:
Module:rtems-source-builder
Branch:master
Commit:abe5d1b2fe9ec264d366b876c1387d7f85aaacd6
Changeset:
http://git.rtems.org/rtems-source-builder/commit/?id=abe5d1b2fe9ec264d366b876c1387d7f85aaacd6
Author:Sebastian Huber
Date: Wed
On 02/07/2020 09:01, Chris Johns wrote:
On 2/7/20 4:06 pm, Sebastian Huber wrote:
Hello,
I filed a bug for this:
https://sourceware.org/bugzilla/show_bug.cgi?id=26194
Fixing this bug needs more time than I can afford.
Where does the requirement for GCC 10 to build the tools come from?
On 2/7/20 4:06 pm, Sebastian Huber wrote:
Hello,
I filed a bug for this:
https://sourceware.org/bugzilla/show_bug.cgi?id=26194
Fixing this bug needs more time than I can afford.
Where does the requirement for GCC 10 to build the tools come from?
Chris
Hello,
I filed a bug for this:
https://sourceware.org/bugzilla/show_bug.cgi?id=26194
Fixing this bug needs more time than I can afford.
--
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
33 matches
Mail list logo
