Hello,
I reworked the heavily out dated system initialization chapter in the RTEMS BSP
and Driver Guide:
https://docs.rtems.org/branches/master/bsp-howto/initilization_code.html
I would be happy if some want to review it.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82
Hello,
any objects to push this patch set with the additional
_Objects_Allocate_with_extend()?
https://lists.rtems.org/pipermail/devel/2020-January/056724.html
I will work on a documentation update afterwards.
- Am 16. Dez 2019 um 15:28 schrieb Sebastian Huber
sebastian.hu...@embedded-bra
Update #3863.
---
cpukit/include/rtems/confdefs.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h
index ffb13fd262..0a63dcc461 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confde
Close #3863.
---
bsp-howto/miscellanous_support.rst | 7 ---
c-user/configuring_a_system.rst| 28
2 files changed, 35 deletions(-)
diff --git a/bsp-howto/miscellanous_support.rst
b/bsp-howto/miscellanous_support.rst
index efb4454..015adb4 100644
--- a/bsp-ho
Remove CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY since it is not needed and
just increases the boot time.
---
testsuites/samples/iostream/system.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/testsuites/samples/iostream/system.h
b/testsuites/samples/iostream/system.h
index 0ae1d8f94f..fbcc56e0
Canonicalize CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY and use
defined/undefined instead of TRUE/FALSE.
Close #3862.
---
cpukit/include/rtems/confdefs.h | 15 +--
testsuites/sptests/sp54/init.c | 5 ++---
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/cpukit/include/rt
Hello,
it seems GCC finished the Git conversion:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=summary
This means our GCC Git mirror refers to a deprecated Git repository.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinf
Use a dedicate system initialization step to zero the memory used for
the workspace and C program heap.
This avoids dead code in case CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY is
not configured.
---
cpukit/Makefile.am | 2 ++
cpukit/include/rtems/confdefs.h| 15 +
Why is this being removed?
--joel
On Tue, Feb 4, 2020 at 6:14 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Update #3863.
> ---
> cpukit/include/rtems/confdefs.h | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/cpukit/include/rtems/confdefs.h
>
On 04/02/2020 14:45, Joel Sherrill wrote:
Why is this being removed?
Please have a look at the ticket:
https://devel.rtems.org/ticket/3863
"BSPs had the option to enable the
CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY via the
BSP_ZERO_WORKSPACE_AUTOMATICALLY BSP option. There is no BSP which
d
Replace the BSP_DIRTY_MEMORY BSP option with a CONFIGURE_DIRTY_MEMORY
configuration option.
Update #3843.
---
bsps/shared/start/bootcard.c| 13
c/src/aclocal/bsp-bootcard-options.m4 | 12 ++-
cpukit/Makefile.am | 1 +
cpukit/include/rtems/c
On 04/02/2020 13:19, sebastian.hu...@embedded-brains.de wrote:
RTEMS Source Builder - Set Builder, 5 (f81b0a519f36)
Host: FreeBSD-12.1-RELEASE-amd64-64bit-ELF
FreeBSD Build_FreeBSD12 12.1-RELEASE FreeBSD 12.1-RELEASE r354233
GENERIC
amd64 amd64
Build Time: 0:05:29.244192
For
On 31/01/2020 18:26, Jan Sommer wrote:
diff --git a/freebsd/sys/sys/mbuf.h b/freebsd/sys/sys/mbuf.h
index ba2e1873..95058e36 100644
--- a/freebsd/sys/sys/mbuf.h
+++ b/freebsd/sys/sys/mbuf.h
@@ -348,6 +348,7 @@ struct mbuf_ext_pgs {
vm_paddr_t pa[MBUF_PEXT_MAX_PGS]; /* phys addrs of
Added pc386 BSP support to rtems-tester.
---
tester/rtems/testing/bsps/pc386.ini | 37 +
1 file changed, 37 insertions(+)
create mode 100644 tester/rtems/testing/bsps/pc386.ini
diff --git a/tester/rtems/testing/bsps/pc386.ini
b/tester/rtems/testing/bsps/pc386
Hi
Posting this rather than just fixing since it seems that this test
is one we would like to keep building.
=
$ make -k >/dev/null
/home/joel/rtems-work/tools/5/lib/gcc/powerpc-rtems5/7.5.0/../../../../powerpc-rtems5/bin/ld:
./../../cpukit/librtemscpu.a(sysinitverbose.o): the
Found by Buildbot here!
https://buildbot.rtems.org/#/builders/19/builds/47
FYI if anyone does want to make a quick check to see if the error is
reproducible Buildbot creates a snapshot with bootstrap already run on every
build for example for this build:
https://buildbot.rtems.org/#/builde
If anyone wants an email when Buildbot fails for a commit you have made please
let me know.
You will get an email when the status changes from Working -> Broken or Broken
-> Working.
Buildbot should be stable enough now that it doesn't have many of its own
errors
and we recently caught breaka
Hello Joel,
the lovely small-data area. I will try to fix this. I probably needs an API
change in .
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Hey Sebastian,
On 2/1/2020 9:23 AM, Sebastian Huber wrote:
> Hello Jeff,
>
> - Am 14. Jan 2020 um 17:37 schrieb Jeff Kubascik
> jeff.kubas...@dornerworks.com:
>
>> Hello,
>>
>> I have noticed a change in the linker section ".rtemsrwset" alignment which
>> has
>> affected the zImage header
- Am 4. Feb 2020 um 21:02 schrieb Jeff Kubascik
jeff.kubas...@dornerworks.com:
> Hey Sebastian,
>
> On 2/1/2020 9:23 AM, Sebastian Huber wrote:
>> Hello Jeff,
>>
>> - Am 14. Jan 2020 um 17:37 schrieb Jeff Kubascik
>> jeff.kubas...@dornerworks.com:
>>
>>> Hello,
>>>
>>> I have noticed a
On 5/2/20 6:05 am, Amar Takhar wrote:
> Buildbot should be stable enough now that it doesn't have many of its own
> errors
> and we recently caught breakage from a commit made.
Many thanks for the buildbot effort and all you do. It is an important part of
RTEMS's development.
Chris
On 5/2/20 6:05 am, Amar Takhar wrote:
> If anyone wants an email when Buildbot fails for a commit you have made
> please
> let me know.
>
> You will get an email when the status changes from Working -> Broken or
> Broken
> -> Working.
Should fails be posted to devel?
Chris
__
On 5/2/20 12:13 am, Sebastian Huber wrote:
> Hello,
>
> it seems GCC finished the Git conversion:
>
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=summary
>
> This means our GCC Git mirror refers to a deprecated Git repository.
Is this the mirror on github?
Does this mean any RSB reference i
On 5/2/20 3:34 am, Lou Woods wrote:
> Added pc386 BSP support to rtems-tester.
How does this differ from pc.ini? Why is a copy needed?
https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/bsps/pc.ini
Chris
___
devel mailing list
devel@rtems.org
On 2020-02-05 10:15 +1100, Chris Johns wrote:
>
> Many thanks for the buildbot effort and all you do. It is an important part of
> RTEMS's development.
Thank you.
Amar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/dev
On 2020-02-05 10:16 +1100, Chris Johns wrote:
>
> Should fails be posted to devel?
I don't think that's a good idea since it's possible that a commit could break
every BSP and then we'll get 1 email per BSP as they each fail.
I think it's okay if the developer breaking the build gets those emai
On 4/2/20 8:20 pm, Sebastian Huber wrote:
> Hello,
>
> I reworked the heavily out dated system initialization chapter in the RTEMS
> BSP and Driver Guide:
>
> https://docs.rtems.org/branches/master/bsp-howto/initilization_code.html
>
> I would be happy if some want to review it.
Looks good. I
On 5/2/20 11:41 am, Amar Takhar wrote:
> On 2020-02-05 10:16 +1100, Chris Johns wrote:
>>
>> Should fails be posted to devel?
>
> I don't think that's a good idea since it's possible that a commit could
> break
> every BSP and then we'll get 1 email per BSP as they each fail.
>
> I think it's o
On 2020-02-05 13:12 +1100, Chris Johns wrote:
> I am OK with that. What do others think?
For example in the last breakage you can see who was responsible by going here
and clicking 'Responsible Users':
https://buildbot.rtems.org/#/builders/19/builds/47
These two would have received direct em
On 05/02/2020 00:18, Chris Johns wrote:
On 5/2/20 12:13 am, Sebastian Huber wrote:
Hello,
it seems GCC finished the Git conversion:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=summary
This means our GCC Git mirror refers to a deprecated Git repository.
Is this the mirror on github?
GCC
On 5/2/20 5:12 pm, Sebastian Huber wrote:
> On 05/02/2020 00:18, Chris Johns wrote:
>>
>> Does this mean any RSB reference in it's history breaks with the new repo?
>
> Yes, in the new GCC repository is a completely new history.
>
Does this mean we can directly reference the new repo and the mir
On 05/02/2020 07:20, Chris Johns wrote:
On 5/2/20 5:12 pm, Sebastian Huber wrote:
On 05/02/2020 00:18, Chris Johns wrote:
Does this mean any RSB reference in it's history breaks with the new repo?
Yes, in the new GCC repository is a completely new history.
Does this mean we can directly ref
On 5/2/20 5:17 pm, Sebastian Huber wrote:
> On 05/02/2020 07:20, Chris Johns wrote:
>
>> On 5/2/20 5:12 pm, Sebastian Huber wrote:
>>> On 05/02/2020 00:18, Chris Johns wrote:
Does this mean any RSB reference in it's history breaks with the new repo?
>>> Yes, in the new GCC repository is a com
On 05/02/2020 03:09, Chris Johns wrote:
On 4/2/20 8:20 pm, Sebastian Huber wrote:
Hello,
I reworked the heavily out dated system initialization chapter in the RTEMS BSP
and Driver Guide:
https://docs.rtems.org/branches/master/bsp-howto/initilization_code.html
I would be happy if some want t
Hello,
this looks like Buildbot is using out of date tools. How are tool
updates (via RSB) triggered for the Buildbot machines?
Forwarded Message
Subject: Buildbot failure in RTEMS on CHECK sparc/erc32 FreeBSD
10.1-STABLE GCC 7.3.0 POSIX
Date: Tue, 04 Feb 2020 06:08:54 +
Hello Amar,
thanks for setting up the Buildbot. I will probably receive most of the
Working -> Broken emails.
If you are subscribed to the bu...@rtems.org mailing list, do you
already get all the information? So an extra subscription to the
Buildbot emails is not necessary?
___
On 5/2/20 5:31 pm, Sebastian Huber wrote:
> On 05/02/2020 03:09, Chris Johns wrote:
>
>> On 4/2/20 8:20 pm, Sebastian Huber wrote:
>>> Hello,
>>>
>>> I reworked the heavily out dated system initialization chapter in the RTEMS
>>> BSP and Driver Guide:
>>>
>>> https://docs.rtems.org/branches/mast
Trying to solve ticket https://devel.rtems.org/ticket/1977
The mode parameter sets access permissions for the created message queue.
Examples:
S_IRUSR 00400 user has read permission
S_IWUSR 00200 user has write permission
S_IXUSR 00100 user has execute permission
Complete list is at: http://man
Update #3865.
---
cpukit/include/rtems/linkersets.h | 16 +---
cpukit/include/rtems/score/percpudata.h | 3 +--
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/cpukit/include/rtems/linkersets.h
b/cpukit/include/rtems/linkersets.h
index 614670338c..844130f0d4 100
39 matches
Mail list logo
