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 -
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
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
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 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/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 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 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
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
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
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
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
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
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
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,
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
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
---
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
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
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
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
21 matches
Mail list logo
