Beaglebone BSP broken after updating new tools

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

Re: [PATCH] RSB: update newlib version built with gcc-4.9.3

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.

Recent Breakage: PowerPC/motorola_powerpc BSPs do not compile

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

Multiple Targets Broken on Same Static Assert

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

[PATCH] score: Add an SMP sequence lock implementation

--- 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

Re: Recent Breakage: PowerPC/motorola_powerpc BSPs do not compile

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

Re: Multiple Targets Broken on Same Static Assert

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

Re: [PATCH] RSB: update newlib version built with gcc-4.9.3

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

[PATCH 5/8] score: Define _Priority_Mask() once

--- .../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

[PATCH 4/8] score: Simplify priority bit map implementation

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

[PATCH 8/8] score: Use builtin for _Bitfield_Find_first_bit()

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

[PATCH 7/8] score: Inline _Bitfield_Find_first_bit()

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

[PATCH 3/8] score: Delete CPU_USE_GENERIC_BITFIELD_DATA

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

[PATCH 2/8] powerpc: Define bitmap defines to FALSE

--- 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

[PATCH 1/8] score: Delete dead copy and paste code

--- 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 -

[PATCH 6/8] score: Define _Priority_Bits_index() once

--- .../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

Re: Beaglebone BSP broken after updating new tools

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

[PATCH] bsps/powerpc: Update to RTEMS printer changes

--- 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

questions about _Thread_queue_Enqueue_critical error path

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

testing pc386 with qemu?

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

Re: testing pc386 with qemu?

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

Re: testing pc386 with qemu?

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

Re: testing pc386 with qemu?

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,

Re: [PATCH] RSB: update newlib version built with gcc-4.9.3

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

Re: Beaglebone BSP broken after updating new tools

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