Yesterday I have updated RTEMS toolchain. I am not able to build
beagle bone bsp. Getting following errors :
error: unknown type name 'fd_set'
error: unknown type name 'pid_t'
Any help to troubleshoot this error will be appreciated. All are
mostly data type error. I tried to look at commit histo
Hi Hesham,
Looks fine to commit. Do you have commit write access?
Chris
On 8/06/2016 8:49 AM, Hesham Almatary wrote:
---
rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.
Hi
On the master, all variants of the motorola_powerpc BSP fail with this:
../../../../../../../../rtems/c/src/lib/libbsp/powerpc/motorola_powerpc/../../powerpc/shared/console/polled_io.c:
In function 'debug_putc':
../../../../../../../../rtems/c/src/lib/libbsp/powerpc/motorola_powerpc/../../powe
Hi
Multiple targets (epiphany, m32c, and or1k as minimum) have a compile error
at this point:
../../cpukit/../../../epiphany_sim/lib/include/rtems/score/basedefs.h:221:17:
error: size of array
'rtems_static_assert_THREAD_QUEUE_SYSLOCK_QUEUE_NEXT_TICKET' is negative
typedef int rtems_static_a
---
cpukit/score/Makefile.am | 1 +
cpukit/score/include/rtems/score/smplockseq.h | 173 +++
cpukit/score/preinstall.am| 4 +
testsuites/smptests/smplock01/init.c | 60 -
testsuites/smptests/smplock01/smplock01.scn | 306
On 08/06/16 14:56, Joel Sherrill wrote:
Hi
On the master, all variants of the motorola_powerpc BSP fail with this:
../../../../../../../../rtems/c/src/lib/libbsp/powerpc/motorola_powerpc/../../powerpc/shared/console/polled_io.c:
In function 'debug_putc':
../../../../../../../../rtems/c/src/lib
On 08/06/16 14:59, Joel Sherrill wrote:
Hi
Multiple targets (epiphany, m32c, and or1k as minimum) have a compile
error at this point:
Yes, these targets must use the latest Newlib. I will check the m32c.
The other use non-FSF tool chains.
--
Sebastian Huber, embedded brains GmbH
Address
On 08/06/16 00:49, Hesham Almatary wrote:
---
rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg
b/rtems/config/tools/rtems-gcc-4.9.3-newlib-2.4.0-1.cfg
index 596a4
---
.../score/include/rtems/score/prioritybitmapimpl.h | 34 +-
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/cpukit/score/include/rtems/score/prioritybitmapimpl.h
b/cpukit/score/include/rtems/score/prioritybitmapimpl.h
index 119e837..fa37189 100644
--- a/cpu
The priority bit map can deal with a maximum of 256 priority values
ranging from 0 to 255. Consistently use an unsigned int for
computation, due to the usual integer promotion rules.
Make Priority_bit_map_Word definition architecture-independent and
define it to uint16_t. This was already the ca
In case the CPU architecture provides no specialized
_CPU_Bitfield_Find_first_bit() macro, then use the __builtin_clz()
builtin in case __GNUC__ is defined.
---
cpukit/score/include/rtems/score/prioritybitmapimpl.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cpukit/score/include/rtems/sc
Turn _Bitfield_Find_first_bit() macro into an inline function.
---
.../score/include/rtems/score/prioritybitmapimpl.h | 55 +-
1 file changed, 23 insertions(+), 32 deletions(-)
diff --git a/cpukit/score/include/rtems/score/prioritybitmapimpl.h
b/cpukit/score/include/rtems/sco
Rename __log2table into _Bitfield_Leading_zeros since it acually returns
the count of leading zeros of an 8-bit integer. The value for zero is a
bit odd. Provide it unconditionally.
---
cpukit/score/cpu/arm/rtems/score/cpu.h | 2 --
cpukit/score/cpu/bfin/rtems/score/cpu.h
---
cpukit/score/cpu/powerpc/rtems/score/cpu.h | 4
1 file changed, 4 insertions(+)
diff --git a/cpukit/score/cpu/powerpc/rtems/score/cpu.h
b/cpukit/score/cpu/powerpc/rtems/score/cpu.h
index 0f5c8d8..287f73d 100644
--- a/cpukit/score/cpu/powerpc/rtems/score/cpu.h
+++ b/cpukit/score/cpu/powe
---
cpukit/score/cpu/bfin/rtems/score/cpu.h | 136 --
cpukit/score/cpu/epiphany/rtems/score/cpu.h | 99 +--
cpukit/score/cpu/lm32/rtems/score/cpu.h | 135 --
cpukit/score/cpu/m32c/rtems/score/cpu.h | 134 -
---
.../score/include/rtems/score/prioritybitmapimpl.h | 38 --
1 file changed, 13 insertions(+), 25 deletions(-)
diff --git a/cpukit/score/include/rtems/score/prioritybitmapimpl.h
b/cpukit/score/include/rtems/score/prioritybitmapimpl.h
index fa37189..ac4c275 100644
--- a/cpu
Did you update the toolchain and rebase to git-pull the HEAD?
On Wed, Jun 8, 2016 at 3:07 AM, punit vara wrote:
> Yesterday I have updated RTEMS toolchain. I am not able to build
> beagle bone bsp. Getting following errors :
>
> error: unknown type name 'fd_set'
> error: unknown type name 'pid_t
---
c/src/lib/libbsp/powerpc/shared/console/polled_io.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/c/src/lib/libbsp/powerpc/shared/console/polled_io.c
b/c/src/lib/libbsp/powerpc/shared/console/polled_io.c
index 76367a1..2ec68d0 100644
--- a/c/src/lib/libb
In threadqenqueue.c:101 the error path will remove the timer and
unblock the thread.
1) The condition for this error is that the wait flags did not match
the expected value. This means some other change occurred in the
thread wait status. I don't even know if this is possible, but if it
does happ
I'm not seeing output with the current pc386 BSP using qemu. I suspect
this is due to some combination of the changes made in the BSP or the
printk support. Any advice?
I have tried to configure with and without USE_COM1_AS_CONSOLE=1, and
run qemu with and without redirecting serial to stdio.
Ged
On 09/06/2016 06:31, Gedare Bloom wrote:
I'm not seeing output with the current pc386 BSP using qemu.
Is this the RSB qemu or another one?
I suspect
this is due to some combination of the changes made in the BSP or the
printk support. Any advice?
I will take a look.
I have tried to config
On Wed, Jun 8, 2016 at 6:58 PM, Chris Johns wrote:
> On 09/06/2016 06:31, Gedare Bloom wrote:
>>
>> I'm not seeing output with the current pc386 BSP using qemu.
>
>
> Is this the RSB qemu or another one?
>
RSB built, but awhile back.
QEMU emulator version 2.3.50, Copyright (c) 2003-2008 Fabrice Be
On 09/06/2016 09:57, Gedare Bloom wrote:
On Wed, Jun 8, 2016 at 6:58 PM, Chris Johns wrote:
On 09/06/2016 06:31, Gedare Bloom wrote:
I'm not seeing output with the current pc386 BSP using qemu.
Is this the RSB qemu or another one?
RSB built, but awhile back.
QEMU emulator version 2.3.50,
On 08/06/2016 23:51, Sebastian Huber wrote:
Given the file name rtems-gcc-4.9.3-newlib-2.4.0-1.cf, how does this fit
to the new file content? We have this *-N.cfg pattern throughout. What
is the rule for the N? Is it useful at all?
This was present when we had no branching in the repo to help m
On Wed, Jun 8, 2016 at 7:33 PM, Gedare Bloom wrote:
> Did you update the toolchain and rebase to git-pull the HEAD?
>
Thank you for response. Yes I successfully able to build RTEMS with
updated tool chain. :)
Thanking you,
Punit Vara
___
devel mailing l
25 matches
Mail list logo