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

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

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)

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

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.

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

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

[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

[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

[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

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

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

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

[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

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

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