[PATCH] config: Hide CONFIGURE_SCHEDULER_COUNT

Rename CONFIGURE_SCHEDULER_COUNT to _CONFIGURE_SCHEDULER_COUNT to emphasise that this is not a user configuration option. --- cpukit/include/rtems/confdefs.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/cpukit/include/rtems/confdefs.h

[PATCH] sim-scripts/qemu-malta.in: New file

--- sim-scripts/Makefile | 5 - sim-scripts/qemu-malta.in | 41 + 2 files changed, 45 insertions(+), 1 deletion(-) create mode 100644 sim-scripts/qemu-malta.in diff --git a/sim-scripts/Makefile b/sim-scripts/Makefile index 5a8a5d2..2ef4a1f

[PATCH] bsps/powerpc: Include to fix the build

This is a hack. The cpukit header file depends on defines provided by the BSP. Update #3425. --- bsps/powerpc/shared/start/bsp-start-zero.S | 2 +- bsps/powerpc/ss555/start/irq_asm.S | 1 + bsps/powerpc/ss555/start/vectors.S | 1 + 3 files changed, 3 insertions(+), 1

[PATCH] sptests: Remove CONFIGURE_MILLISECONDS_PER_TICK

This configuration define is not supported. --- testsuites/sptests/sp69/init.c| 2 -- testsuites/sptests/sprmsched02/init.c | 2 -- 2 files changed, 4 deletions(-) diff --git a/testsuites/sptests/sp69/init.c b/testsuites/sptests/sp69/init.c index 6a5e139d34..38c40ccdf8 100644 ---

[PATCH] score: Simplify _Objects_Name_to_string()

Do not use isprint() from since it depends on the heavy weight C locale implementation in Newlib. --- cpukit/score/src/objectgetnameasstring.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/cpukit/score/src/objectgetnameasstring.c

Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

Hi all, While cross-compiling fio for RTEMS, by default in the compiler call > -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 options are used which raises the following error: > /home/uka_in/development/benchmark/sandbox/5/lib/gcc/arm-rtems5/7.3.0/include/ssp/unistd.h:38:10: > fatal error: ssp.h: No

Re: Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

Hi! I don't know the specifics of the thing you're talking about here, so others should definitely weigh in on that if they can, but regarding the header file; the include syntax used (, as opposed to "ssp.h") is the one used for system header files (for eg. vs "my_header.h"). I see 2

Re: [GSoC] Ways to make the x86_64 port work with UEFI

On Fri, May 25, 2018, 11:15 AM Amaan Cheval wrote: > Hey! > > Skippable details about how FreeBSD handles the UEFI boot process! > > > > Having looked into it a bit more, my understanding of

Re: [PATCH] bsps/powerpc: Include to fix the build

It was dependent on the CFLAGS including a -D. Or some cases, the -mcpu option provided the CPU define expected. But virtex and ss555 provide -mcpu and -D options (now in bspopts.h) which are contradictory. This fixes (or covers up) most of an issue but those two BSPs need their CPU flags

Re: Covoar address to line to DWARF updates.

On Fri, 25 May 2018, 09:26 Vijay Kumar Banerjee, wrote: > > > On Fri, 25 May 2018, 02:52 Chris Johns, wrote: > >> On 25/5/18 7:11 am, Vijay Kumar Banerjee wrote: >> > On Fri, 25 May 2018, 00:35 Joel Sherrill, > >

Re: Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

Am 25.05.2018 um 17:14 schrieb Joel Sherrill: > > > On Fri, May 25, 2018 at 10:09 AM, Amaan Cheval > wrote: > > Hi! > > I don't know the specifics of the thing you're talking about here, > so others should definitely weigh in

Re: [GSoC] Ways to make the x86_64 port work with UEFI

Hey! Skippable details about how FreeBSD handles the UEFI boot process! Having looked into it a bit more, my understanding of how FreeBSD handles this process is: - They build a two-stage bootloader for EFI, called

Re: Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

On Fri, May 25, 2018 at 10:09 AM, Amaan Cheval wrote: > Hi! > > I don't know the specifics of the thing you're talking about here, so > others should definitely weigh in on that if they can, but regarding the > header file; the include syntax used (, as opposed to

Re: [GSoC] Ways to make the x86_64 port work with UEFI

On Fri, May 25, 2018, 12:11 PM Amaan Cheval wrote: > Hey! Could you link me to some code that you used for the Deos setup > you mentioned? > My understanding is that the -shared option can link static archives > to create a "shared" library in the sense that it doesn't

Re: [GSoC] Ways to make the x86_64 port work with UEFI

Hey! Could you link me to some code that you used for the Deos setup you mentioned? My understanding is that the -shared option can link static archives to create a "shared" library in the sense that it doesn't include the usual crt0 runtime environment and whatnot, but the code within is still

Re: Where does the content of release report come from?

Hi Chris, Thank you so much for your instruction, I would write these two python modules for ticket list and tickets at first. Best, Dannie On Thu, May 24, 2018 at 2:15 PM, Chris Johns wrote: > On 25/5/18 12:52 am, Joel Sherrill wrote: > > I suggested in irc yesterday that

[PATCH] bsp/atsam: Remove side effect from gmac functions.

Quite a number of GMAC_... functions had a side effect of enabling the transmit and receive. During the initialization of the ethernet driver, that lead to the situation that the receive has been already enabled while the DMA isn't set up correctly. Therefore the DMA interpreted the values at

Re: Symbol Size Variance

On 25/05/18 07:54, Sebastian Huber wrote: On 24/05/18 17:46, Gedare Bloom wrote: On Thu, May 24, 2018 at 9:05 AM, Joel Sherrill wrote: On Thu, May 24, 2018, 8:04 AM Gedare Bloom wrote: On Wed, May 23, 2018 at 2:28 AM, Sebastian Huber

[PATCH] config: Hide CONFIGURE_INITIAL_EXTENSION_TABLE

Rename CONFIGURE_INITIAL_EXTENSION_TABLE to _CONFIGURE_INITIAL_EXTENSION_TABLE to emphasise that this is not a user configuration option. --- cpukit/include/rtems/confdefs.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/cpukit/include/rtems/confdefs.h