Re: Test failures on arm/realview_pbx_a9_qemu
On 5/11/2014 6:14 pm, Sebastian Huber wrote: on the latest Git master the following new tests fail on arm/realview_pbx_a9_qemu due to a timeout after 180 seconds: top, dl01.pre and dl02.pre. The dl01.pre and dl02.pre are not to be run. They are the first link of two to get a suitable set of symbols. I will change the Makefile to not create exe files. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Add GPIO, I2C and SPI support for the RPi BSP
I'm in support of putting bsp-specific examples in examples-v2. And renaming the repository... Reducing repo sprawl is good. -Gedare On Wed, Nov 5, 2014 at 12:32 AM, Chris Johns wrote: > On 5/11/2014 2:40 pm, Gedare Bloom wrote: >> >> These are ideal for BSP-specific testing framework, which we presently >> lack. I'm not certain where they should go. > > > What about examples-v2 ? You could add a boards directory and the code under > arch/bsp. The waf build system lets you know when a specific arch/bsp is > being built. > >> Maybe a repo for BSP-specific examples is a useful idea. > > > I am attempting to lower the number of repos we have. Every repo needs > testing. > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] libbsp ARM: create abort.h to eliminate warnings Created libbsp/arm/shared/abort/abort.h Edited abort.c and simple_abort.c to include abort.h Changed Raspberry Pi BSP to use abort.c instea
I'm not sure any of the ARM BSPs use the abort.c or simple_abort.c, even if they have the code included. I don't have access to the code right now, but I will take a look at the ARM BSPs and remove it from the ones that use the shared start.S. If the ARM BSPs that do not use the shared start.S include the code, but never call it, I can remove it, if that is what is best. We could even remove abort.c and simple_abort.c completely. Just let me know. Alan On Mon, Nov 3, 2014 at 3:08 PM, Joel Sherrill wrote: > > On 11/3/2014 5:22 AM, Alan Cudmore wrote: > > OK, that makes sense. I'll fix it and resubmit the patch. Any other ARM > BSPs? > > > The warning only shows up in these: > > $ grep abort.c warnings-20141030a.txt > 2 c/src/lib/libbsp/arm/rtl22xx/../shared/abort/simple_abort.c:56:6: > warning: no previous prototype for '_print_full_context' > [-Wmissing-prototypes] > 2 c/src/lib/libbsp/arm/rtl22xx/../shared/abort/simple_abort.c:108:6: > warning: no previous prototype for 'do_data_abort' [-Wmissing-prototypes] > 1 > c/src/lib/libbsp/arm/raspberrypi/../shared/abort/simple_abort.c:56:6: > warning: no previous prototype for '_print_full_context' > [-Wmissing-prototypes] > 1 > c/src/lib/libbsp/arm/raspberrypi/../shared/abort/simple_abort.c:108:6: > warning: no previous prototype for 'do_data_abort' [-Wmissing-prototypes] > > which matches a grep: > > $ grep simple_abort.c */M*am > raspberrypi/Makefile.am:libbsp_a_SOURCES += ../shared/abort/simple_abort.c > rtl22xx/Makefile.am:libbsp_a_SOURCES += ../shared/abort/simple_abort.c > > When I "grep start.S */M*.am" from libbsp/arm, most BSPs use > shared/start/start.S > but a few have their own start.S. Not sure what the impact of that is. > > --joel > > > Alan > On Nov 3, 2014 2:03 AM, "Sebastian Huber" < > sebastian.hu...@embedded-brains.de> wrote: > >> On 03/11/14 02:59, Alan Cudmore wrote: >> >>> -libbsp_a_SOURCES += ../shared/abort/simple_abort.c >>> +libbsp_a_SOURCES += ../shared/abort/abort.c >>> >> >> Since this BSP uses the shared start.S file, I would prefer to remove >> simple_abort.c and abort.c from the Makefile.am. These files should go >> away in the long run. >> >> The default abort handler is now in: >> >> >> http://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/armv4-exception-default.S >> >> -- >> Sebastian Huber, embedded brains GmbH >> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany >> Phone : +49 89 189 47 41-16 >> Fax : +49 89 189 47 41-09 >> E-Mail : sebastian.hu...@embedded-brains.de >> PGP : Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> > > -- > Joel Sherrill, Ph.D. Director of Research & > developmentjoel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] libbsp ARM: create abort.h to eliminate warnings Created libbsp/arm/shared/abort/abort.h Edited abort.c and simple_abort.c to include abort.h Changed Raspberry Pi BSP to use abort.c instea
On 05/11/14 15:35, Alan Cudmore wrote: If the ARM BSPs that do not use the shared start.S include the code, but never call it, I can remove it, if that is what is best. We could even remove abort.c and simple_abort.c completely. Just let me know. It would be best to get rid of these files. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Add GPIO, I2C and SPI support for the RPi BSP
This is a tough problem. We have plenty of inexpensive SPI and I2C devices to mix and match with low cost boards such as the Pi and Beaglebone, but it could all become obsolete quickly. If we put a bunch of SPI and I2C drivers in the RTEMS repo, then how do we test and maintain them without duplicating a custom breadboard setup? Even an examples repo will have to come with a schematic to build the setup necessary to run a program. I have RTEMS drivers for some of the devices I have connected to my Pi, such as the DS1302 RTC, an I2C GPIO expansion port, and an LCD display. I was going to expand my RKI application to have a driver framework, so these type of drivers could be integrated and tested without having to integrate them into the RTEMS tree and BSP. Alan On Wed, Nov 5, 2014 at 9:32 AM, Gedare Bloom wrote: > I'm in support of putting bsp-specific examples in examples-v2. And > renaming the repository... > > Reducing repo sprawl is good. > > -Gedare > > On Wed, Nov 5, 2014 at 12:32 AM, Chris Johns wrote: > > On 5/11/2014 2:40 pm, Gedare Bloom wrote: > >> > >> These are ideal for BSP-specific testing framework, which we presently > >> lack. I'm not certain where they should go. > > > > > > What about examples-v2 ? You could add a boards directory and the code > under > > arch/bsp. The waf build system lets you know when a specific arch/bsp is > > being built. > > > >> Maybe a repo for BSP-specific examples is a useful idea. > > > > > > I am attempting to lower the number of repos we have. Every repo needs > > testing. > > > > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: Test failures on arm/realview_pbx_a9_qemu
How are interactive tests being handled now? The top test will eventually end but would come closest to being considered interactive. Jennifer Averett > -Original Message- > From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian > Huber > Sent: Wednesday, November 05, 2014 1:14 AM > To: RTEMS > Subject: Test failures on arm/realview_pbx_a9_qemu > > Hello, > > on the latest Git master the following new tests fail on > arm/realview_pbx_a9_qemu due to a timeout after 180 seconds: top, > dl01.pre and dl02.pre. > > Attached are the log files. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Add GPIO, I2C and SPI support for the RPi BSP
A standalone framework for drivers would be quite useful. That, or improved support for drivers (HAL) in RTEMS is needed to achieve a maintainable solution. -Gedare On Wed, Nov 5, 2014 at 10:10 AM, Alan Cudmore wrote: > This is a tough problem. We have plenty of inexpensive SPI and I2C devices > to mix and match with low cost boards such as the Pi and Beaglebone, but it > could all become obsolete quickly. > If we put a bunch of SPI and I2C drivers in the RTEMS repo, then how do we > test and maintain them without duplicating a custom breadboard setup? > > Even an examples repo will have to come with a schematic to build the setup > necessary to run a program. > > I have RTEMS drivers for some of the devices I have connected to my Pi, such > as the DS1302 RTC, an I2C GPIO expansion port, and an LCD display. I was > going to expand my RKI application to have a driver framework, so these type > of drivers could be integrated and tested without having to integrate them > into the RTEMS tree and BSP. > > Alan > > On Wed, Nov 5, 2014 at 9:32 AM, Gedare Bloom wrote: >> >> I'm in support of putting bsp-specific examples in examples-v2. And >> renaming the repository... >> >> Reducing repo sprawl is good. >> >> -Gedare >> >> On Wed, Nov 5, 2014 at 12:32 AM, Chris Johns wrote: >> > On 5/11/2014 2:40 pm, Gedare Bloom wrote: >> >> >> >> These are ideal for BSP-specific testing framework, which we presently >> >> lack. I'm not certain where they should go. >> > >> > >> > What about examples-v2 ? You could add a boards directory and the code >> > under >> > arch/bsp. The waf build system lets you know when a specific arch/bsp is >> > being built. >> > >> >> Maybe a repo for BSP-specific examples is a useful idea. >> > >> > >> > I am attempting to lower the number of repos we have. Every repo needs >> > testing. >> > >> > Chris >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/5] shell/main_edit.c: Fix warnings
---
cpukit/libmisc/shell/main_edit.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c
index fc7775c..0feb828 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -781,7 +781,7 @@ static void outstr(char *str) {
fputs(str, stdout);
}
-static void clear_screen() {
+static void clear_screen(void) {
outstr(CLRSCR);
}
@@ -809,7 +809,7 @@ static void get_modifier_keys(int *shift, int *ctrl) {
#endif
}
-static int getachar()
+static int getachar(void)
{
int ch = getchar();
#if KEY_HISTORY
@@ -823,7 +823,7 @@ static int getachar()
return ch;
}
-static int getkey() {
+static int getkey(void) {
int ch, shift, ctrl;
ch = getachar();
@@ -1058,7 +1058,7 @@ static int prompt(struct editor *ed, char *msg, int
selection) {
}
}
-static int ask() {
+static int ask(void) {
int ch = getachar();
return ch == 'y' || ch == 'Y';
}
@@ -1918,7 +1918,7 @@ static void goto_line(struct editor *ed) {
ed->refresh = 1;
}
-struct editor *next_file(struct editor *ed) {
+static struct editor *next_file(struct editor *ed) {
ed = ed->env->current = ed->next;
ed->refresh = 1;
return ed;
@@ -2156,14 +2156,16 @@ static void edit(struct editor *ed) {
//
// main
//
-
-int rtems_shell_main_edit(int argc, char *argv[]) {
+static int rtems_shell_main_edit(int argc, char *argv[])
+{
struct env env;
int rc;
int i;
sigset_t blocked_sigmask, orig_sigmask;
-#if defined(__linux__) || defined(__rtems__)
+#if defined(__linux__)
struct termios tio;
+#endif
+#if defined(__linux__) || defined(__rtems__)
struct termios orig_tio;
#endif
#ifdef SANOS
--
1.9.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/5] lpc1768_mbed_ahb_ram_eth-testsuite.tcfg: Add a handful more tests
--- .../lpc176x/make/custom/lpc1768_mbed_ahb_ram_eth-testsuite.tcfg | 8 1 file changed, 8 insertions(+) diff --git a/c/src/lib/libbsp/arm/lpc176x/make/custom/lpc1768_mbed_ahb_ram_eth-testsuite.tcfg b/c/src/lib/libbsp/arm/lpc176x/make/custom/lpc1768_mbed_ahb_ram_eth-testsuite.tcfg index a9bfaf4..8c5e239 100644 --- a/c/src/lib/libbsp/arm/lpc176x/make/custom/lpc1768_mbed_ahb_ram_eth-testsuite.tcfg +++ b/c/src/lib/libbsp/arm/lpc176x/make/custom/lpc1768_mbed_ahb_ram_eth-testsuite.tcfg @@ -16,8 +16,16 @@ jffs2_fsrdwr jffs2_fssymlink jffs2_fstime mghttpd01 +monitor01 +monitor02 pppd +psxconfig01 rbheap01 +sp16 +sp25 +sp48 +spregion_err01 +spstkalloc spstkalloc02 utf8proc01 iostream -- 1.9.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 5/5] lpc23xx_tli800-testsuite.tcfg: Add dl02
--- c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg | 1 + 1 file changed, 1 insertion(+) diff --git a/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg b/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg index 5d303a9..9c10352 100644 --- a/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg +++ b/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg @@ -7,6 +7,7 @@ capture cdtest dl01 +dl02 fileio flashdisk01 fsdosfsformat01 -- 1.9.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/5] lm3s3749-testsuite.tcfg: Add dl02
--- c/src/lib/libbsp/arm/lm3s69xx/make/custom/lm3s3749-testsuite.tcfg | 1 + 1 file changed, 1 insertion(+) diff --git a/c/src/lib/libbsp/arm/lm3s69xx/make/custom/lm3s3749-testsuite.tcfg b/c/src/lib/libbsp/arm/lm3s69xx/make/custom/lm3s3749-testsuite.tcfg index 30aaea0..9462da2 100644 --- a/c/src/lib/libbsp/arm/lm3s69xx/make/custom/lm3s3749-testsuite.tcfg +++ b/c/src/lib/libbsp/arm/lm3s69xx/make/custom/lm3s3749-testsuite.tcfg @@ -7,6 +7,7 @@ capture iostream dl01 +dl02 ftp01 fileio flashdisk01 -- 1.9.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 4/5] lpc2362-testsuite.tcfg: Add dl02
--- c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc2362-testsuite.tcfg | 1 + 1 file changed, 1 insertion(+) diff --git a/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc2362-testsuite.tcfg b/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc2362-testsuite.tcfg index 1559e3d..d1b31fa 100644 --- a/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc2362-testsuite.tcfg +++ b/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc2362-testsuite.tcfg @@ -7,6 +7,7 @@ capture cdtest dl01 +dl02 fileio flashdisk01 fsdosfsname01 -- 1.9.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Run-Time Loader Build Failures
Hi I just thought I would post a summary after the recent updates and include all targets in one easy to track email. Overall about 50% of the architectures fail to build for some reason or another. + Unrecognized symbol type from a .s file bfin (all BSPs), i386 (all BSPs), powerpc (all BSPs) + undefined reference to `rtems__rtl_base_globals_size' and `rtems__rtl_base_globals' h8300 (all BSPs) + ICE compiling rtl-obj.c. Reported to GCC as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741 lm32 (all BSPs) + All MIPS BSPs have an error in exec_elf.h at line 54. error: 'ELF32_MACHDEP_ID_CASES' undeclared (first use in this function) #define ELFDEFNNAME(x) CONCAT(ELF,CONCAT(ELFSIZE,CONCAT(_,x))) + moxie - error: machine-type: unknown machine type: 65261 + v850 - error: machine-type: unknown machine type: 36 + nios2 - build error: ../../../../../../rtems/c/src/../../cpukit/libdl/rtl-mdreloc-nios2.c:27:1: error: conflicting types for 'rtems_rtl_elf_relocate_rela' rtems_rtl_elf_relocate_rela (rtems_rtl_obj_t* obj, ^ In file included from ../../../../../../rtems/c/src/../../cpukit/libdl/rtl-mdreloc-nios2.c:15:0: ../../../../../../rtems/c/src/../../cpukit/libdl/rtl-elf.h:102:6: note: previous declaration of 'rtems_rtl_elf_relocate_rela' was here bool rtems_rtl_elf_relocate_rela (const rtems_rtl_obj_t* obj, ^ ../../../../../../rtems/c/src/../../cpukit/libdl/rtl-mdreloc-nios2.c:37:1: error: conflicting types for 'rtems_rtl_elf_relocate_rel' rtems_rtl_elf_relocate_rel (rtems_rtl_obj_t* obj, -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-tools commit] linkers: Disable .type statements in symbol code.
Which targets do you think this fixes?
On November 5, 2014 7:02:32 PM CST, Chris Johns wrote:
>Module:rtems-tools
>Branch:master
>Commit:b9c0a0436d387429035241d3d4d03446b6f915cf
>Changeset:
>http://git.rtems.org/rtems-tools/commit/?id=b9c0a0436d387429035241d3d4d03446b6f915cf
>
>Author:Chris Johns
>Date: Thu Nov 6 12:05:38 2014 +1100
>
>linkers: Disable .type statements in symbol code.
>
>Some of the assemblers do not support this statement.
>
>---
>
> linkers/rtems-syms.cpp |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
>diff --git a/linkers/rtems-syms.cpp b/linkers/rtems-syms.cpp
>index 24cc56d..6f167e3 100644
>--- a/linkers/rtems-syms.cpp
>+++ b/linkers/rtems-syms.cpp
>@@ -80,16 +80,20 @@ static const char* c_trailer[] =
> {
> "asm(\" .byte0\");",
> "asm(\" .ascii \\\"\\xde\\xad\\xbe\\xef\\\"\");",
>+#if BROKEN_ON_SOME_ASSEMBLERS
> "asm(\" .typertems__rtl_base_globals, #object\");",
>"asm(\" .sizertems__rtl_base_globals, . -
>rtems__rtl_base_globals\");",
>+#endif
> "",
> "/*",
> " * Symbol table size.",
> " */",
> "asm(\" .align 4\");",
> "asm(\" .local rtems__rtl_base_globals_size\");",
>+#if BROKEN_ON_SOME_ASSEMBLERS
> "asm(\" .typertems__rtl_base_globals_size, #object\");",
> "asm(\" .sizertems__rtl_base_globals_size, 4\");",
>+#endif
> "asm(\"rtems__rtl_base_globals_size:\");",
>"asm(\" .long rtems__rtl_base_globals_size -
>rtems__rtl_base_globals\");",
> "",
>
>___
>vc mailing list
>v...@rtems.org
>http://lists.rtems.org/mailman/listinfo/vc
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Run-Time Loader Build Failures
On 6/11/2014 11:08 am, Joel Sherrill wrote: I just thought I would post a summary after the recent updates and include all targets in one easy to track email. Overall about 50% of the architectures fail to build for some reason or another. + Unrecognized symbol type from a .s file bfin (all BSPs), i386 (all BSPs), powerpc (all BSPs) The i386 is now building. You need to update your rtems-tools to get a fixed rtems-syms. It seems some assemblers do not handle the .type statement while other do, or there are some variants that the rtems-syms did not handle. I have removed inserting a .type statement. The bfin tools are not build for me. I get: /opt/work/rtems/rsb/chris/rtems-source-builder.master/rtems/build/bfin-rtems4.11-gcc-4.9.2-newlib-9b9f839addfe16ab0fd11f09a30a28139bfae6d5-1/build/./gcc/xgcc -B/opt/work/rtems/rsb/chris/rtems-source-builder.master/rtems/build/bfin-rtems4.11-gcc-4.9.2-newlib-9b9f839addfe16ab0fd11f09a30a28139bfae6d5-1/build/./gcc/ -nostdinc -B/opt/work/rtems/rsb/chris/rtems-source-builder.master/rtems/build/bfin-rtems4.11-gcc-4.9.2-newlib-9b9f839addfe16ab0fd11f09a30a28139bfae6d5-1/build/bfin-rtems4.11/newlib/ -isystem /opt/work/rtems/rsb/chris/rtems-source-builder.master/rtems/build/bfin-rtems4.11-gcc-4.9.2-newlib-9b9f839addfe16ab0fd11f09a30a28139bfae6d5-1/build/bfin-rtems4.11/newlib/targ-include -isystem /opt/work/rtems/rsb/chris/rtems-source-builder.master/rtems/build/bfin-rtems4.11-gcc-4.9.2-newlib-9b9f839addfe16ab0fd11f09a30a28139bfae6d5-1/gcc-4.9.2/newlib/libc/include -B/opt/work/rtems/4.11/bfin-rtems4.11/bin/ -B/opt/work/rtems/4.11/bfin-rtems4.11/lib/ -isystem /opt/work/rtems/4.11/bfin-rtems4.11/include -isystem /opt/work/rtems/4.11/bfin-rtems4.11/sys-include-g -O2 -O2 -I../../../gcc-4.9.2/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../.././gcc -I../../../gcc-4.9.2/libgcc -I../../../gcc-4.9.2/libgcc/. -I../../../gcc-4.9.2/libgcc/../gcc -I../../../gcc-4.9.2/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _ge_sf.o -MT _ge_sf.o -MD -MP -MF _ge_sf.dep -DFINE_GRAINED_LIBRARIES -DL_ge_sf -DFLOAT -c ../../../gcc-4.9.2/libgcc/fp-bit.c -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc-4.9.2/libgcc/fp-bit.c: In function '__divsf3': ../../../gcc-4.9.2/libgcc/fp-bit.c:1082:1: internal compiler error: in cfg_layout_initialize, at cfgrtl.c:4233 } ^ Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-tools commit] linkers: Disable .type statements in symbol code.
On 6/11/2014 12:15 pm, Joel Sherrill wrote: Which targets do you think this fixes? The i386 now builds. See my other email. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Test failures on arm/realview_pbx_a9_qemu
Hello Jennifer, yes, there are some interactive tests in the test suite, but do we really need new ones? Who has the time to do interactive testing? The other interactive tests wait some seconds for user input and otherwise exit. I think it is preferable to turn this top test into a non-interactive test. On 05/11/14 16:34, Jennifer Averett wrote: How are interactive tests being handled now? The top test will eventually end but would come closest to being considered interactive. Jennifer Averett -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber Sent: Wednesday, November 05, 2014 1:14 AM To: RTEMS Subject: Test failures on arm/realview_pbx_a9_qemu Hello, on the latest Git master the following new tests fail on arm/realview_pbx_a9_qemu due to a timeout after 180 seconds: top, dl01.pre and dl02.pre. Attached are the log files. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 Branching To Do
Hello, I have a new item for the list: Very desirable == + Since red-black trees are now used to implement the priority queues and they will play an important part in future SMP improvements I would like to do some performance measurements with alternative implementations. I would like to compare 1. the RTEMS red-black tree implementation, 2. the RTEMS red-black tree implementation with the colour encoded in the parent pointer, 3. the implementation from Eternally Confuzzled, see http://www.eternallyconfuzzled.com/tuts/datastructures/jsw_tut_rbtree.aspx, 4. the BSD implementation , and 5. the JFFS2 implementation (cpukit/libfs/src/jffs2/include/linux/rbtree.h), see http://lwn.net/Articles/184495/. I intend to use real hardware ARM, ColdFire, PowerPC and SPARC targets. Do we have other interesting red-black tree implementations? On 29/10/14 22:49, Joel Sherrill wrote: Hi Since we are long over due for a release. I can count 4 new children and a grandchild among the core developers since 4.10. :) Here is what I have off the top of my head: Mandatory == + Tool version selection - Likely gcc 4.9 on almost all targets. - binutils last release - newlib TBD - GDB could be new release + BeagleBoard BSP added + Run-Time Loader merged and tested + Visit the Getting Started manual. It is dated. + Push a bit more on warnings. - Three BSPs represent bulk of remaining warnings Very desirable = + x86 context switch SMP handoff logic + Pi GSOC Code merged. Anything else? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
