On 20/11/17 02:18, Chris Johns wrote:
On 18/11/2017 19:15, Sebastian Huber wrote:
It would be nice if we are able to back port fixes from the next master (6.0.0)
to RTEMS 5.1 easily. I guess RTEMS 5.1 could be a long term release since all
the work for SMP which resulted in a massive re-writ
On 20/11/17 02:18, Chris Johns wrote:
then you have the complexity
of 3 separate VME.h files in BSPs, 2 each of vmeTsi148.h and vmeTsi148DMA.h. I
have no idea if these files are the same or different. These would need to be
audited and changed with the corresponding changes to the source.
I fou
Hello,
there are some dead links on the website www.rtems.org in the "Releases
and Active Development" box:
"Release page"
"here"
Link name is wrong in "Documentation":
"4.12 Manuals" -> Development Master Manuals"
"4.12 Doxygen" -> Development Master Doxygen"
--
Sebastian Huber, embedded b
---
c/src/lib/libbsp/sparc/shared/1553/gr1553rt.c | 182 ++
1 file changed, 69 insertions(+), 113 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/shared/1553/gr1553rt.c
b/c/src/lib/libbsp/sparc/shared/1553/gr1553rt.c
index 22378bf..932e849 100644
--- a/c/src/lib/libbsp/s
Ok, thanks.
--
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 Mit
On Mon, Nov 20, 2017 at 7:49 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
> there are some dead links on the website www.rtems.org in the "Releases
> and Active Development" box:
>
> "Release page"
> "here"
>
The URL was right, there was a missing quote on both so t
Thanks for the update.
On 20/11/17 15:25, Joel Sherrill wrote:
Is there somewhere to send people to explain the release numbering
change?
Ideally the new engineering manual. For now:
https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5SeriesAndHigherNumbering
--
Sebastian Huber,
Hi
This would seem to put a deadline on properly supporting UEFI. Looks like
we need at least a 32-bit non-legacy PC BSP. Even better would be both 32
and 64-bit non-legacy mode PC BSPs.
http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf
This will require help fro
On Sat, Nov 18, 2017 at 11:40 AM, Joel Sherrill wrote:
>
>
> On Nov 18, 2017 10:29 AM, "Sebastian Huber"
> wrote:
>
> Hello,
>
> all the POSIX synchronization objects use thread queues. Each thread queue
> has a name member. It would be nice to have a function to set this name.
> Unfortunately th
Hi
Why does sptimecounter01 define CONFIGURE_TASK_STACK_ALLOCATOR
and CONFIGURE_TASK_STACK_DEALLOCATOR to NULL?
I ask because I have an out of tree paravirtualized BSP that has to provide
BSP specific stack management to account for the memory protection it
operates within. Not using those alloca
Hi
I was doing a test sweep of the GCC master since GCC 8 is coming up and I
wanted to pass along that doing a "make -j" on a 6 real code (12
hyper-threaded) CentOS 7 computer resulted in all *rtems targets failing to
build.
Does anyone have insight into this or know the GCC PR to pile onto? I
re
Based on correlation with the enum for object lookup errors in
cpukit/score/include/rtems/score/objectimpl.h:
typedef enum {
OBJECTS_NAME_OR_ID_LOOKUP_SUCCESSFUL,
OBJECTS_INVALID_NAME,
OBJECTS_INVALID_ADDRESS,
OBJECTS_INVALID_ID,
OBJECTS_INVALID_NODE
} Objects_Name_or_id_lookup_errors;
updat
Hi
Looks like with -j1, there are real build failures -- so far on arm, i386
and sparc:
checking for sparc-rtems5-gcc...
/home/joel/test-gcc/b-sparc-rtems5-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-sparc-rtems5-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-sparc-rtems5-gcc/sparc-rtems5/newlib/ -isyst
On Tue, Nov 7, 2017 at 10:27 AM, Joel Sherrill wrote:
>
>
> On Mon, Nov 6, 2017 at 5:23 PM, Hesham Almatary
> wrote:
>>
>> Hi,
>>
>> I've come across this page [1], but it hasn't been updated since 2011.
>> I'm wondering what's the status of Clang project and how feasible it's
>> to build RTEMS w
On 21/11/2017 04:26, Joel Sherrill wrote:
>
> I was doing a test sweep of the GCC master since GCC 8 is coming up and I
> wanted
> to pass along that doing a "make -j" on a 6 real code (12 hyper-threaded)
> CentOS
> 7 computer resulted in all *rtems targets failing to build.
>
> Does anyone ha
On 21/11/2017 04:27, Joel Sherrill wrote:
> I think we should push this off and focus on fixing the blocking issues.
> This will happen in time. Doing it now could push the release out many
> more months. I know Sebastian and I wanted it out earlier this year.
I think it is worth exploring a littl
On 20/11/17 23:01, Joel Sherrill wrote:
This means that we need a __getreent() stub in the stub crt0.c found
in newlib.
I already fixed this in the Newlib master yesterday.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41
On 21/11/17 04:33, Chris Johns wrote:
On 21/11/2017 04:27, Joel Sherrill wrote:
I think we should push this off and focus on fixing the blocking issues.
This will happen in time. Doing it now could push the release out many
more months. I know Sebastian and I wanted it out earlier this year.
I
On 20/11/17 17:53, Joel Sherrill wrote:
The purpose of defining these to NULL isn't documented in this test
and renders this test broken for what seems to be a reason orthogonal
to the test's apparent purpose.
This test runs in a minimal environment (test runs in boot_card()) to
verify the
Update #3243.
---
cpukit/posix/src/pthreadinitthreads.c | 26 ++--
cpukit/rtems/src/taskinitusers.c | 24 ++--
cpukit/score/Makefile.am | 1 -
cpukit/score/include/rtems/score/threadimpl.h | 23
cpukit/score/src/threadglobalconstruction.c
Delete superfluous INTERNAL_ERROR_POSIX_INIT_THREAD_ENTRY_IS_NULL.
Update #3243.
---
cpukit/posix/src/pthreadinitthreads.c | 8 +---
cpukit/score/include/rtems/score/interr.h | 2 +-
testsuites/psxtests/psxfatal01/testcase.h | 2 +-
3 files changed, 3 insertions(+), 9 deletions(-)
diff -
21 matches
Mail list logo
