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
OK, that makes sense. I'll fix it and resubmit the patch. Any other ARM BSPs? 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] top: Resolve compile errors.
---
cpukit/libmisc/cpuuse/cpuusagetop.c | 83 -
1 file changed, 63 insertions(+), 20 deletions(-)
diff --git a/cpukit/libmisc/cpuuse/cpuusagetop.c
b/cpukit/libmisc/cpuuse/cpuusagetop.c
index 7e7348a..ecafd00 100644
--- a/cpukit/libmisc/cpuuse/cpuusagetop.c
+++ b/cpukit/libmisc/cpuuse/cpuusagetop.c
@@ -30,13 +30,11 @@
#include rtems/score/todimpl.h
#include rtems/score/watchdogimpl.h
-
/*
* Common variable to sync the load monitor task.
*/
static volatile int rtems_cpuusage_top_thread_active;
-
typedef struct {
void *context;
rtems_printk_plugin_t print;
@@ -44,13 +42,56 @@ typedef struct {
#define RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS (20)
+
+static inline bool Equal_to_uint32_t( uint32_t * lhs, uint32_t * rhs )
+{
+ if ( *lhs == *rhs )
+ return true;
+ else
+ return false;
+}
+
+static inline void Set_uint32_t( uint32_t * lhs, uint32_t * rhs )
+{
+ *lhs = *rhs;
+}
+
+static inline bool Less_than_uint32_t( uint32_t * lhs, uint32_t * rhs )
+{
+ if ( *lhs *rhs )
+return true;
+ else
+return false;
+}
+
+#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
+ #define _Thread_CPU_usage_Equal_to( _lhs, _rhs ) \
+ _Timestamp_Equal_to( _lhs, _rhs )
+#else
+ #define _Thread_CPU_usage_Equal_to( _lhs, _rhs ) \
+ Equal_to_uint32_t( _lhs, _rhs )
+#endif
+
+#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
+#define _Thread_CPU_usage_Set_to_zero( _time ) \
+ _Timestamp_Set_to_zero( _time )
+#else
+#define _Thread_CPU_usage_Set_to_zero( _time ) \
+ Set_uint32_t( _time, 0 );
+#endif
+
+#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
+#define _Thread_CPU_usage_Less_than( _lhs, _rhs ) \
+_Timestamp_Less_than( _lhs, _rhs )
+#else
+#define _Thread_CPU_usage_Less_than( _lhs, _rhs ) \
+ Less_than_uint32_t( _lhs, _rhs )
+#endif
+
/*
* rtems_cpuusage_top_thread
*
- * DESCRIPTION:
- *
* This function displays the load of the tasks on an ANSI terminal.
- *
*/
static void
@@ -62,25 +103,29 @@ rtems_cpuusage_top_thread (rtems_task_argument arg)
int j;
int k;
Objects_Information* information;
-charname[13];
+ char name[13];
int task_count = 0;
uint32_t seconds, nanoseconds;
rtems_cpu_usage_plugin_t* plugin = (rtems_cpu_usage_plugin_t*)arg;
Thread_Control* load_tasks[RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS + 1];
- unsigned long longload[RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS + 1];
+ Thread_CPU_usage_tload[RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS + 1];
+ Thread_CPU_usage_tzero;
+ Timestamp_Control uptime;
+ uint32_t ival, fval;
- while (true)
- {
+ while (true) {
#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
- Timestamp_Control uptime, total, ran, uptime_at_last_reset;
+ Timestamp_Control total, ran, uptime_at_last_reset;
#else
uint32_t total_units = 0;
#endif
rtems_cpuusage_top_thread_active = 1;
+_Thread_CPU_usage_Set_to_zero( zero);
memset (load_tasks, 0, sizeof (load_tasks));
-memset (load, 0, sizeof (load));
+for (i=0; i (RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS + 1); i++)
+ _Thread_CPU_usage_Set_to_zero( load[i] );
/*
* Iterate over the tasks and sort the highest load tasks
@@ -98,8 +143,7 @@ rtems_cpuusage_top_thread (rtems_task_argument arg)
for ( k=1 ; k = information-maximum ; k++ ) {
the_thread = (Thread_Control *)information-local_table[ k ];
if ( the_thread ) {
-
-Thread_CPU_usage_t l = the_thread-cpu_time_used;
+Thread_CPU_usage_t usage = the_thread-cpu_time_used;
/*
* When not using nanosecond CPU usage resolution, we have to
count
@@ -107,14 +151,15 @@ rtems_cpuusage_top_thread (rtems_task_argument arg)
* guideline as to what each number means proportionally.
*/
#ifdef __RTEMS_USE_TICKS_FOR_STATISTICS__
- total_units += l;
+ total_units += usage;
#endif
/* Count the number of tasks and sort this load value */
task_count++;
for (i = 0; i RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS; i++) {
if (load_tasks[i]) {
-if ((l == 0) || (l load[i]))
+if ( _Thread_CPU_usage_Equal_to( usage, zero) ||
+ _Thread_CPU_usage_Less_than( usage, load[i]))
continue;
for (j = (RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS - 1); j = i; j--){
load_tasks[j + 1] = load_tasks[j];
@@ -122,7 +167,7 @@ rtems_cpuusage_top_thread (rtems_task_argument arg)
}
}
load_tasks[i] = the_thread;
- load[i] = l;
+ load[i] = usage;
break;
Re: [PATCH] (2 commits squashed into one) Beagle BSP for review
Hi,
I don't have time to review, but am OK in principle with committing
this code as it is tested, with the caveat that my previous comments
be addressed post-merge.
If you have a diff / commits on top of what you sent before, I'd be
glad to give those a quick look.
Thanks for your contribution!
Gedare
On Mon, Nov 3, 2014 at 7:20 AM, Ben Gras b...@shrike-systems.com wrote:
All,
Ok, as promised, I rebased and re-tested and have found included a
portable way of making the SD card image (included in sdcard.sh), to be
merged with RSB (i.e. some of the tools sdcard.sh relies on are missing in
mainline RSB). Some of Gedare's initial feedback is processed thanks to
Brandon Matthews. It's tested to run on the original beaglebone, beaglebone
black and qemu linaro. (The assumption is it'll run on the bbxm hardware as
well as it was before rebasing.)
The result is split into 2 patches to show what was Claas's initial work.
This makes them a bit unreadable for the final result from the patches
unfortunately.
As before, see
http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
on how to build all the tools, RTEMS executables, sdcard images, and run the
test set from linaro qemu.
On Sat, Aug 30, 2014 at 5:50 PM, Ben Gras b...@shrike-systems.com wrote:
All,
OK, that seems like a fruitful way to proceed to me.
Then I will do some minor cleanups, rebase, do all the tests again, and
re-submit. There's just one problem I know of that I want to fix before the
first commit happens, and that is that the FAT fs made by mtools doesn't
boot on the HW it seems. (It does on the emulator.) A last-minute change -
switching to mtools instead of dosfstools to use to make the SD card image
because the latter is so linux-only.
Stay tuned.
On Wed, Aug 20, 2014 at 4:20 PM, Gedare Bloom ged...@rtems.org wrote:
Ben, As far as getting this merged, all of my comments can be done as
a follow-on commit. -Gedare
On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com
wrote:
Thanks for the fast detailed review. Let me get back to it/you.
In the meantime, any other feedback? From anyone I mean.
On Thu, Jul 24, 2014 at 4:45 PM, Gedare Bloom ged...@rtems.org wrote:
Hi Ben,
Great work. I have a few comments. I skipped the i2c.h and i2c.c
files. Most of my comments are about style and a few requests to
refactor some of the larger files. The refactoring can be added to
your TODO if you like. Please fix the style issues if it is not a
burden.
+++ b/c/src/lib/libbsp/arm/beagle/README
+$ ../claas-rtems/configure --target=arm-rtems4.11
--enable-rtemsbsp=beaglebonewhite beagleboardxm
Replace claas-rtems with rtems. If RSB support is available, make a
note about it.
+++ b/c/src/lib/libbsp/arm/beagle/TODO
[...]
open:
+ . how to handle the interrupt?
What does this mean?
+++ b/c/src/lib/libbsp/arm/beagle/clock.c
Why is the entire file ifdef'd on ARM_MULTILIB_ARCH_V4?
It might be sensible to put the struct definitions in a .h file if
these omap registers might be re-usable.
+static struct omap_timer_registers regs_v2 = {
This might be better to put behind an #if IS_AM335X since it is not
used otherwise?
+
+
+
Avoid more than one blank line in a row.
+static int done = 0;
It would be nice if you got rid of this, but otherwise give it a more
useful name like mmio_init_done
+static void beagle_clock_handler_install(rtems_interrupt_handler isr)
+ if (sc != RTEMS_SUCCESSFUL) {
+rtems_fatal_error_occurred(0xdeadbeef);
I think there is some capabilities in ARM for bsp fatal error codes
now. They should be preferred to be used to help debug these fatal
conditions.
+static inline uint32_t beagle_clock_nanoseconds_since_last_tick(void)
+ return (read_frc() - (uint64_t) last_tick_nanoseconds) * 10
/ FRCLOCK_HZ;
This line is 80 characters, please break it or shrink it.
+++ b/c/src/lib/libbsp/arm/beagle/console/console-config.c
+#define CONSOLE_UART_LSR (*(volatile unsigned int
*)(BSP_CONSOLE_UART_BASE+0x14))
Line 80 characters, even with the spacing modified.
+static void beagle_console_init(void)
+while ((CONSOLE_SYSS 1) == 0)
+ ;
Is this a fatal loop or is it waiting for hardware to clear something?
+if ((CONSOLE_LSR (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) ==
CONSOLE_LSR_THRE) {
Again 80 characters. Is the test logically equivalent to: if (
(CONSOLE_LSR CONSOLE_LSR_THRE) == CONSOLE_LSR_THRE)
+while ((CONSOLE_LSR CONSOLE_LSR_TEMT) == 0)
+ ;
Is this a fatal loop or is it waiting for hardware?
+++ b/c/src/lib/libbsp/arm/beagle/include/bsp.h
This bsp.h is really long. Probably it should be refactored into other
headers, including non-public ones.
+static inline void dsb(void)
+{
+asm volatile(dsb : : : memory);
Fix the indentation.
Re: [PATCH] top: Resolve compile errors.
On Mon, Nov 3, 2014 at 7:58 AM, Jennifer Averett
jennifer.aver...@oarcorp.com wrote:
---
cpukit/libmisc/cpuuse/cpuusagetop.c | 83
-
1 file changed, 63 insertions(+), 20 deletions(-)
diff --git a/cpukit/libmisc/cpuuse/cpuusagetop.c
b/cpukit/libmisc/cpuuse/cpuusagetop.c
index 7e7348a..ecafd00 100644
--- a/cpukit/libmisc/cpuuse/cpuusagetop.c
+++ b/cpukit/libmisc/cpuuse/cpuusagetop.c
@@ -30,13 +30,11 @@
#include rtems/score/todimpl.h
#include rtems/score/watchdogimpl.h
-
/*
* Common variable to sync the load monitor task.
*/
static volatile int rtems_cpuusage_top_thread_active;
-
typedef struct {
void *context;
rtems_printk_plugin_t print;
@@ -44,13 +42,56 @@ typedef struct {
#define RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS (20)
+
+static inline bool Equal_to_uint32_t( uint32_t * lhs, uint32_t * rhs )
+{
+ if ( *lhs == *rhs )
+ return true;
+ else
+ return false;
+}
+
+static inline void Set_uint32_t( uint32_t * lhs, uint32_t * rhs )
+{
+ *lhs = *rhs;
+}
+
+static inline bool Less_than_uint32_t( uint32_t * lhs, uint32_t * rhs )
+{
+ if ( *lhs *rhs )
+return true;
+ else
+return false;
+}
What is the purpose for these functions? If they're only used in the
macros below, you could probably just write them directly into the
macro body. Otherwise, I'd prefer they use all lower-case names for
consistent readability. [In the future, it may be sensible to include
a way to distinguish 'private' (static-local) functions and variables,
but for now we have no such convention, so we should stick to naming
things in the usual way.]
+
+#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
+ #define _Thread_CPU_usage_Equal_to( _lhs, _rhs ) \
+ _Timestamp_Equal_to( _lhs, _rhs )
+#else
+ #define _Thread_CPU_usage_Equal_to( _lhs, _rhs ) \
+ Equal_to_uint32_t( _lhs, _rhs )
(*_lhs == *_rhs)
+#endif
+
+#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
+#define _Thread_CPU_usage_Set_to_zero( _time ) \
+ _Timestamp_Set_to_zero( _time )
+#else
+#define _Thread_CPU_usage_Set_to_zero( _time ) \
+ Set_uint32_t( _time, 0 );
This is almost certainly wrong, and could be replaced by
*_time = 0
The function Set_uint32_t defined above takes pointers, passing 0 (or
any literal integer) and treating it as a pointer, then derefencing
it, is bad.
+#endif
+
+#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
+#define _Thread_CPU_usage_Less_than( _lhs, _rhs ) \
+_Timestamp_Less_than( _lhs, _rhs )
+#else
+#define _Thread_CPU_usage_Less_than( _lhs, _rhs ) \
+ Less_than_uint32_t( _lhs, _rhs )
(*_lhs *_rhs)
+#endif
+
/*
* rtems_cpuusage_top_thread
*
- * DESCRIPTION:
- *
* This function displays the load of the tasks on an ANSI terminal.
- *
*/
static void
@@ -62,25 +103,29 @@ rtems_cpuusage_top_thread (rtems_task_argument arg)
int j;
int k;
Objects_Information* information;
-charname[13];
+ char name[13];
int task_count = 0;
uint32_t seconds, nanoseconds;
rtems_cpu_usage_plugin_t* plugin = (rtems_cpu_usage_plugin_t*)arg;
Thread_Control* load_tasks[RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS +
1];
- unsigned long longload[RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS + 1];
+ Thread_CPU_usage_tload[RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS + 1];
+ Thread_CPU_usage_tzero;
+ Timestamp_Control uptime;
+ uint32_t ival, fval;
- while (true)
- {
+ while (true) {
#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
- Timestamp_Control uptime, total, ran, uptime_at_last_reset;
+ Timestamp_Control total, ran, uptime_at_last_reset;
#else
uint32_t total_units = 0;
#endif
rtems_cpuusage_top_thread_active = 1;
+_Thread_CPU_usage_Set_to_zero( zero);
memset (load_tasks, 0, sizeof (load_tasks));
-memset (load, 0, sizeof (load));
+for (i=0; i (RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS + 1); i++)
+ _Thread_CPU_usage_Set_to_zero( load[i] );
/*
* Iterate over the tasks and sort the highest load tasks
@@ -98,8 +143,7 @@ rtems_cpuusage_top_thread (rtems_task_argument arg)
for ( k=1 ; k = information-maximum ; k++ ) {
the_thread = (Thread_Control *)information-local_table[ k ];
if ( the_thread ) {
-
-Thread_CPU_usage_t l = the_thread-cpu_time_used;
+Thread_CPU_usage_t usage = the_thread-cpu_time_used;
/*
* When not using nanosecond CPU usage resolution, we have to
count
@@ -107,14 +151,15 @@ rtems_cpuusage_top_thread (rtems_task_argument arg)
* guideline as to what each number means proportionally.
*/
#ifdef
Re: [PATCH] top: Resolve compile errors.
On November 3, 2014 8:12:11 AM CST, Gedare Bloom ged...@rtems.org wrote:
On Mon, Nov 3, 2014 at 7:58 AM, Jennifer Averett
jennifer.aver...@oarcorp.com wrote:
---
cpukit/libmisc/cpuuse/cpuusagetop.c | 83
-
1 file changed, 63 insertions(+), 20 deletions(-)
diff --git a/cpukit/libmisc/cpuuse/cpuusagetop.c
b/cpukit/libmisc/cpuuse/cpuusagetop.c
index 7e7348a..ecafd00 100644
--- a/cpukit/libmisc/cpuuse/cpuusagetop.c
+++ b/cpukit/libmisc/cpuuse/cpuusagetop.c
@@ -30,13 +30,11 @@
#include rtems/score/todimpl.h
#include rtems/score/watchdogimpl.h
-
/*
* Common variable to sync the load monitor task.
*/
static volatile int rtems_cpuusage_top_thread_active;
-
typedef struct {
void *context;
rtems_printk_plugin_t print;
@@ -44,13 +42,56 @@ typedef struct {
#define RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS (20)
+
+static inline bool Equal_to_uint32_t( uint32_t * lhs, uint32_t * rhs
)
+{
+ if ( *lhs == *rhs )
+ return true;
+ else
+ return false;
+}
+
+static inline void Set_uint32_t( uint32_t * lhs, uint32_t * rhs )
+{
+ *lhs = *rhs;
+}
+
+static inline bool Less_than_uint32_t( uint32_t * lhs, uint32_t *
rhs )
+{
+ if ( *lhs *rhs )
+return true;
+ else
+return false;
+}
What is the purpose for these functions? If they're only used in the
macros below, you could probably just write them directly into the
macro body. Otherwise, I'd prefer they use all lower-case names for
consistent readability. [In the future, it may be sensible to include
a way to distinguish 'private' (static-local) functions and variables,
but for now we have no such convention, so we should stick to naming
things in the usual way.
Without addressing this, the code did not compile on some targets. The
representation of CPU usage statistics is selected by the port or user.
Jennifer can address your style comments
+
+#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
+ #define _Thread_CPU_usage_Equal_to( _lhs, _rhs ) \
+ _Timestamp_Equal_to( _lhs, _rhs )
+#else
+ #define _Thread_CPU_usage_Equal_to( _lhs, _rhs ) \
+ Equal_to_uint32_t( _lhs, _rhs )
(*_lhs == *_rhs)
+#endif
+
+#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
+#define _Thread_CPU_usage_Set_to_zero( _time ) \
+ _Timestamp_Set_to_zero( _time )
+#else
+#define _Thread_CPU_usage_Set_to_zero( _time ) \
+ Set_uint32_t( _time, 0 );
This is almost certainly wrong, and could be replaced by
*_time = 0
The function Set_uint32_t defined above takes pointers, passing 0 (or
any literal integer) and treating it as a pointer, then derefencing
it, is bad.
+#endif
+
+#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
+#define _Thread_CPU_usage_Less_than( _lhs, _rhs ) \
+_Timestamp_Less_than( _lhs, _rhs )
+#else
+#define _Thread_CPU_usage_Less_than( _lhs, _rhs ) \
+ Less_than_uint32_t( _lhs, _rhs )
(*_lhs *_rhs)
+#endif
+
/*
* rtems_cpuusage_top_thread
*
- * DESCRIPTION:
- *
* This function displays the load of the tasks on an ANSI terminal.
- *
*/
static void
@@ -62,25 +103,29 @@ rtems_cpuusage_top_thread (rtems_task_argument
arg)
int j;
int k;
Objects_Information* information;
-charname[13];
+ char name[13];
int task_count = 0;
uint32_t seconds, nanoseconds;
rtems_cpu_usage_plugin_t* plugin = (rtems_cpu_usage_plugin_t*)arg;
Thread_Control*
load_tasks[RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS + 1];
- unsigned long longload[RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS +
1];
+ Thread_CPU_usage_tload[RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS +
1];
+ Thread_CPU_usage_tzero;
+ Timestamp_Control uptime;
+ uint32_t ival, fval;
- while (true)
- {
+ while (true) {
#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
- Timestamp_Control uptime, total, ran, uptime_at_last_reset;
+ Timestamp_Control total, ran, uptime_at_last_reset;
#else
uint32_t total_units = 0;
#endif
rtems_cpuusage_top_thread_active = 1;
+_Thread_CPU_usage_Set_to_zero( zero);
memset (load_tasks, 0, sizeof (load_tasks));
-memset (load, 0, sizeof (load));
+for (i=0; i (RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS + 1); i++)
+ _Thread_CPU_usage_Set_to_zero( load[i] );
/*
* Iterate over the tasks and sort the highest load tasks
@@ -98,8 +143,7 @@ rtems_cpuusage_top_thread (rtems_task_argument
arg)
for ( k=1 ; k = information-maximum ; k++ ) {
the_thread = (Thread_Control *)information-local_table[ k
];
if ( the_thread ) {
-
-Thread_CPU_usage_t l = the_thread-cpu_time_used;
+Thread_CPU_usage_t usage = the_thread-cpu_time_used;
/*
* When not using
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 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 mailto: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 tel:%2B49%2089%20189%2047%2041-16 Fax : +49 89 189 47 41-09 tel:%2B49%2089%20189%2047%2041-09 E-Mail : sebastian.hu...@embedded-brains.de mailto: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 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: [PATCH] (2 commits squashed into one) Beagle BSP for review
All,
Joel merged these and I updated my blog post to reflect the mainline repo.
Thanks Joel!
On Mon, Nov 3, 2014 at 8:40 PM, Ben Gras b...@shrike-systems.com wrote:
All,
I have new patches with some last-minute smoothings added; removed
obsolete beagle.cfg, TODO, and separated the more generic ARM headers into
a separate commit. The new 3 commits are attached (and in my RTEMS github
repo).
Gedare, there is also a diff w.r.t. the previous submission attached as
requested.
On Mon, Nov 3, 2014 at 3:01 PM, Gedare Bloom ged...@rtems.org wrote:
Hi,
I don't have time to review, but am OK in principle with committing
this code as it is tested, with the caveat that my previous comments
be addressed post-merge.
If you have a diff / commits on top of what you sent before, I'd be
glad to give those a quick look.
Thanks for your contribution!
Gedare
On Mon, Nov 3, 2014 at 7:20 AM, Ben Gras b...@shrike-systems.com wrote:
All,
Ok, as promised, I rebased and re-tested and have found included a
portable way of making the SD card image (included in sdcard.sh), to be
merged with RSB (i.e. some of the tools sdcard.sh relies on are missing
in
mainline RSB). Some of Gedare's initial feedback is processed thanks to
Brandon Matthews. It's tested to run on the original beaglebone,
beaglebone
black and qemu linaro. (The assumption is it'll run on the bbxm
hardware as
well as it was before rebasing.)
The result is split into 2 patches to show what was Claas's initial
work.
This makes them a bit unreadable for the final result from the patches
unfortunately.
As before, see
http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
on how to build all the tools, RTEMS executables, sdcard images, and
run the
test set from linaro qemu.
On Sat, Aug 30, 2014 at 5:50 PM, Ben Gras b...@shrike-systems.com
wrote:
All,
OK, that seems like a fruitful way to proceed to me.
Then I will do some minor cleanups, rebase, do all the tests again, and
re-submit. There's just one problem I know of that I want to fix
before the
first commit happens, and that is that the FAT fs made by mtools
doesn't
boot on the HW it seems. (It does on the emulator.) A last-minute
change -
switching to mtools instead of dosfstools to use to make the SD card
image
because the latter is so linux-only.
Stay tuned.
On Wed, Aug 20, 2014 at 4:20 PM, Gedare Bloom ged...@rtems.org
wrote:
Ben, As far as getting this merged, all of my comments can be done as
a follow-on commit. -Gedare
On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com
wrote:
Thanks for the fast detailed review. Let me get back to it/you.
In the meantime, any other feedback? From anyone I mean.
On Thu, Jul 24, 2014 at 4:45 PM, Gedare Bloom ged...@rtems.org
wrote:
Hi Ben,
Great work. I have a few comments. I skipped the i2c.h and i2c.c
files. Most of my comments are about style and a few requests to
refactor some of the larger files. The refactoring can be added to
your TODO if you like. Please fix the style issues if it is not a
burden.
+++ b/c/src/lib/libbsp/arm/beagle/README
+$ ../claas-rtems/configure --target=arm-rtems4.11
--enable-rtemsbsp=beaglebonewhite beagleboardxm
Replace claas-rtems with rtems. If RSB support is available, make a
note about it.
+++ b/c/src/lib/libbsp/arm/beagle/TODO
[...]
open:
+ . how to handle the interrupt?
What does this mean?
+++ b/c/src/lib/libbsp/arm/beagle/clock.c
Why is the entire file ifdef'd on ARM_MULTILIB_ARCH_V4?
It might be sensible to put the struct definitions in a .h file if
these omap registers might be re-usable.
+static struct omap_timer_registers regs_v2 = {
This might be better to put behind an #if IS_AM335X since it is not
used otherwise?
+
+
+
Avoid more than one blank line in a row.
+static int done = 0;
It would be nice if you got rid of this, but otherwise give it a
more
useful name like mmio_init_done
+static void beagle_clock_handler_install(rtems_interrupt_handler
isr)
+ if (sc != RTEMS_SUCCESSFUL) {
+rtems_fatal_error_occurred(0xdeadbeef);
I think there is some capabilities in ARM for bsp fatal error codes
now. They should be preferred to be used to help debug these fatal
conditions.
+static inline uint32_t
beagle_clock_nanoseconds_since_last_tick(void)
+ return (read_frc() - (uint64_t) last_tick_nanoseconds) *
10
/ FRCLOCK_HZ;
This line is 80 characters, please break it or shrink it.
+++ b/c/src/lib/libbsp/arm/beagle/console/console-config.c
+#define CONSOLE_UART_LSR (*(volatile unsigned int
*)(BSP_CONSOLE_UART_BASE+0x14))
Line 80 characters, even with the spacing modified.
+static void beagle_console_init(void)
+while ((CONSOLE_SYSS
dl01 failure on i386/pc386
Hi rtems-syms -e -c -mtune=i386 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -o dl-sym.o dl01.pre.exe /tmp/ccobfWoY.s: Assembler messages: /tmp/ccobfWoY.s:2196: Error: unrecognized symbol type /tmp/ccobfWoY.s:2200: Error: unrecognized symbol type error: compiling wrapper: Compiler error gmake[7]: *** [dl-sym.o] Error 10 gmake[7]: Leaving directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-i386-pc386-rtems/i386-rtems4.11/c/pc386/testsuites/libtests/dl01' -- 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
dl01 failure on h8300/h8sim
Hi rtems-syms -e -c -mh -mint32 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -o dl-sym.o dl01.pre.exe h8300-rtems4.11-gcc -B../../../../../h8sim/lib/ -specs bsp_specs -qrtems -mh -mint32 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -mh -mint32 \ -o dl01.exe init.o dl-load.o dl-tar.o dl-sym.o dl-sym.o: In function `rtems_rtl_base_global_syms_init': rld--Ubdaaa.c:(.text+0xa): undefined reference to `rtems__rtl_base_globals_size' rld--Ubdaaa.c:(.text+0x10): undefined reference to `rtems__rtl_base_globals' collect2: error: ld returned 1 exit status gmake[7]: *** [dl01.exe] Error 1 -- 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: [PATCH] (2 commits squashed into one) Beagle BSP for review
On 11/3/2014 3:06 PM, Ben Gras wrote: All, Joel merged these and I updated my blog post to reflect the mainline repo. Thanks Joel! Thank you Ben for the nice submission!!! Now to make sure it is reproducible from here and we have merged all the bits into the tools, etc. On Mon, Nov 3, 2014 at 8:40 PM, Ben Gras b...@shrike-systems.com mailto:b...@shrike-systems.com wrote: All, I have new patches with some last-minute smoothings added; removed obsolete beagle.cfg, TODO, and separated the more generic ARM headers into a separate commit. The new 3 commits are attached (and in my RTEMS github repo). Gedare, there is also a diff w.r.t. the previous submission attached as requested. On Mon, Nov 3, 2014 at 3:01 PM, Gedare Bloom ged...@rtems.org mailto:ged...@rtems.org wrote: Hi, I don't have time to review, but am OK in principle with committing this code as it is tested, with the caveat that my previous comments be addressed post-merge. If you have a diff / commits on top of what you sent before, I'd be glad to give those a quick look. Thanks for your contribution! Gedare On Mon, Nov 3, 2014 at 7:20 AM, Ben Gras b...@shrike-systems.com mailto:b...@shrike-systems.com wrote: All, Ok, as promised, I rebased and re-tested and have found included a portable way of making the SD card image (included in sdcard.sh), to be merged with RSB (i.e. some of the tools sdcard.sh relies on are missing in mainline RSB). Some of Gedare's initial feedback is processed thanks to Brandon Matthews. It's tested to run on the original beaglebone, beaglebone black and qemu linaro. (The assumption is it'll run on the bbxm hardware as well as it was before rebasing.) The result is split into 2 patches to show what was Claas's initial work. This makes them a bit unreadable for the final result from the patches unfortunately. As before, see http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html on how to build all the tools, RTEMS executables, sdcard images, and run the test set from linaro qemu. On Sat, Aug 30, 2014 at 5:50 PM, Ben Gras b...@shrike-systems.com mailto:b...@shrike-systems.com wrote: All, OK, that seems like a fruitful way to proceed to me. Then I will do some minor cleanups, rebase, do all the tests again, and re-submit. There's just one problem I know of that I want to fix before the first commit happens, and that is that the FAT fs made by mtools doesn't boot on the HW it seems. (It does on the emulator.) A last-minute change - switching to mtools instead of dosfstools to use to make the SD card image because the latter is so linux-only. Stay tuned. On Wed, Aug 20, 2014 at 4:20 PM, Gedare Bloom ged...@rtems.org mailto:ged...@rtems.org wrote: Ben, As far as getting this merged, all of my comments can be done as a follow-on commit. -Gedare On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com mailto:b...@shrike-systems.com wrote: Thanks for the fast detailed review. Let me get back to it/you. In the meantime, any other feedback? From anyone I mean. On Thu, Jul 24, 2014 at 4:45 PM, Gedare Bloom ged...@rtems.org mailto:ged...@rtems.org wrote: Hi Ben, Great work. I have a few comments. I skipped the i2c.h and i2c.c files. Most of my comments are about style and a few requests to refactor some of the larger files. The refactoring can be added to your TODO if you like. Please fix the style issues if it is not a burden. +++ b/c/src/lib/libbsp/arm/beagle/README +$ ../claas-rtems/configure --target=arm-rtems4.11 --enable-rtemsbsp=beaglebonewhite beagleboardxm Replace claas-rtems with rtems. If RSB support is available, make a note about it. +++ b/c/src/lib/libbsp/arm/beagle/TODO [...] open: + . how to handle the interrupt? What does this mean? +++ b/c/src/lib/libbsp/arm/beagle/clock.c
lm32 rtl-error.c causes gcc ICE
Hi I suppose this needs to be narrowed down and fed into gcc's bugzilla. But I wanted to here from Chris first. lm32-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../lm32_evr/lib/include -DRTEMS_RTL_RAP_LOADER=1 -DRTEMS_RTL_ELF_LOADER=1 -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libdl_a-rtl-obj.o -MD -MP -MF .deps/libdl_a-rtl-obj.Tpo -c -o libdl_a-rtl-obj.o `test -f 'rtl-obj.c' || echo '../../../../../../rtems/c/src/../../cpukit/libdl/'`rtl-obj.c 0x70a8b5 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc-4.9.1/gcc/rtl-error.c:109 0x70a8e9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc-4.9.1/gcc/rtl-error.c:117 0x93096e insn_default_length(rtx_def*) /users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/lm32-rtems4.11-gcc-4.9.1-newlib-19-Aug-2014-1/build/gcc/insn-attrtab.c:143 0x595e8a shorten_branches(rtx_def*) ../../gcc-4.9.1/gcc/final.c:1191 0x5962ef rest_of_handle_shorten_branches ../../gcc-4.9.1/gcc/final.c:4519 0x5962ef execute ../../gcc-4.9.1/gcc/final.c:4548 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. -- 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: [PATCH] (2 commits squashed into one) Beagle BSP for review
Indeed. I did right away verify I can build run test everything for the
beaglebones and the bbxm from mainline. So that seems to have gone fine.
The supporting tools and RSB stuff I am in contact with Chris about.
On Mon, Nov 3, 2014 at 10:23 PM, Joel Sherrill joel.sherr...@oarcorp.com
wrote:
On 11/3/2014 3:06 PM, Ben Gras wrote:
All,
Joel merged these and I updated my blog post to reflect the mainline
repo. Thanks Joel!
Thank you Ben for the nice submission!!!
Now to make sure it is reproducible from here and we have merged
all the bits into the tools, etc.
On Mon, Nov 3, 2014 at 8:40 PM, Ben Gras b...@shrike-systems.com wrote:
All,
I have new patches with some last-minute smoothings added; removed
obsolete beagle.cfg, TODO, and separated the more generic ARM headers into
a separate commit. The new 3 commits are attached (and in my RTEMS github
repo).
Gedare, there is also a diff w.r.t. the previous submission attached as
requested.
On Mon, Nov 3, 2014 at 3:01 PM, Gedare Bloom ged...@rtems.org wrote:
Hi,
I don't have time to review, but am OK in principle with committing
this code as it is tested, with the caveat that my previous comments
be addressed post-merge.
If you have a diff / commits on top of what you sent before, I'd be
glad to give those a quick look.
Thanks for your contribution!
Gedare
On Mon, Nov 3, 2014 at 7:20 AM, Ben Gras b...@shrike-systems.com
wrote:
All,
Ok, as promised, I rebased and re-tested and have found included a
portable way of making the SD card image (included in sdcard.sh), to be
merged with RSB (i.e. some of the tools sdcard.sh relies on are
missing in
mainline RSB). Some of Gedare's initial feedback is processed thanks to
Brandon Matthews. It's tested to run on the original beaglebone,
beaglebone
black and qemu linaro. (The assumption is it'll run on the bbxm
hardware as
well as it was before rebasing.)
The result is split into 2 patches to show what was Claas's initial
work.
This makes them a bit unreadable for the final result from the patches
unfortunately.
As before, see
http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
on how to build all the tools, RTEMS executables, sdcard images, and
run the
test set from linaro qemu.
On Sat, Aug 30, 2014 at 5:50 PM, Ben Gras b...@shrike-systems.com
wrote:
All,
OK, that seems like a fruitful way to proceed to me.
Then I will do some minor cleanups, rebase, do all the tests again,
and
re-submit. There's just one problem I know of that I want to fix
before the
first commit happens, and that is that the FAT fs made by mtools
doesn't
boot on the HW it seems. (It does on the emulator.) A last-minute
change -
switching to mtools instead of dosfstools to use to make the SD card
image
because the latter is so linux-only.
Stay tuned.
On Wed, Aug 20, 2014 at 4:20 PM, Gedare Bloom ged...@rtems.org
wrote:
Ben, As far as getting this merged, all of my comments can be done as
a follow-on commit. -Gedare
On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com
wrote:
Thanks for the fast detailed review. Let me get back to it/you.
In the meantime, any other feedback? From anyone I mean.
On Thu, Jul 24, 2014 at 4:45 PM, Gedare Bloom ged...@rtems.org
wrote:
Hi Ben,
Great work. I have a few comments. I skipped the i2c.h and i2c.c
files. Most of my comments are about style and a few requests to
refactor some of the larger files. The refactoring can be added to
your TODO if you like. Please fix the style issues if it is not a
burden.
+++ b/c/src/lib/libbsp/arm/beagle/README
+$ ../claas-rtems/configure --target=arm-rtems4.11
--enable-rtemsbsp=beaglebonewhite beagleboardxm
Replace claas-rtems with rtems. If RSB support is available, make
a
note about it.
+++ b/c/src/lib/libbsp/arm/beagle/TODO
[...]
open:
+ . how to handle the interrupt?
What does this mean?
+++ b/c/src/lib/libbsp/arm/beagle/clock.c
Why is the entire file ifdef'd on ARM_MULTILIB_ARCH_V4?
It might be sensible to put the struct definitions in a .h file if
these omap registers might be re-usable.
+static struct omap_timer_registers regs_v2 = {
This might be better to put behind an #if IS_AM335X since it is
not
used otherwise?
+
+
+
Avoid more than one blank line in a row.
+static int done = 0;
It would be nice if you got rid of this, but otherwise give it a
more
useful name like mmio_init_done
+static void beagle_clock_handler_install(rtems_interrupt_handler
isr)
+ if (sc != RTEMS_SUCCESSFUL) {
+rtems_fatal_error_occurred(0xdeadbeef);
I think there is some capabilities in ARM for bsp fatal error
codes
now. They should be preferred to be used to help debug these fatal
conditions.
+static
Re: m32c libdl build error
On 4/11/2014 8:26 am, Joel Sherrill wrote: Hi Looks like a Makefile/configure issue. Seems so. There is no relocation code for m32c. There is for m32r. Chris gmake[6]: Entering directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-m32c-m32csim-rtems/m32c-rtems4.11/c/m32csim/cpukit/libdl' gmake[6]: *** No rule to make target `preinstall'. Stop. gmake[6]: Leaving directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-m32c-m32csim-rtems/m32c-rtems4.11/c/m32csim/cpukit/libdl' gmake[5]: *** [preinstall-recursive] Error 1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: m32c libdl build error
On 11/3/2014 3:29 PM, Chris Johns wrote: On 4/11/2014 8:26 am, Joel Sherrill wrote: Hi Looks like a Makefile/configure issue. Seems so. There is no relocation code for m32c. There is for m32r. Got a quick fix? This looks like the easiest of the failures so far. :( --joel Chris gmake[6]: Entering directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-m32c-m32csim-rtems/m32c-rtems4.11/c/m32csim/cpukit/libdl' gmake[6]: *** No rule to make target `preinstall'. Stop. gmake[6]: Leaving directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-m32c-m32csim-rtems/m32c-rtems4.11/c/m32csim/cpukit/libdl' gmake[5]: *** [preinstall-recursive] Error 1 -- 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: m32c libdl build error
On 4/11/2014 8:30 am, Joel Sherrill wrote: On 11/3/2014 3:29 PM, Chris Johns wrote: On 4/11/2014 8:26 am, Joel Sherrill wrote: Hi Looks like a Makefile/configure issue. Seems so. There is no relocation code for m32c. There is for m32r. Got a quick fix? This looks like the easiest of the failures so far. :( I checked the lists on cpukit/configure.ac and libtest/configure.ac and m32c is not listed and so LIBDL empties the Makefile. Does this mean a dummy preinstall target is needed ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: lm32 rtl-error.c causes gcc ICE
On 4/11/2014 8:25 am, Joel Sherrill wrote: Hi I suppose this needs to be narrowed down and fed into gcc's bugzilla. But I wanted to here from Chris first. lm32-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../lm32_evr/lib/include -DRTEMS_RTL_RAP_LOADER=1 -DRTEMS_RTL_ELF_LOADER=1 -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libdl_a-rtl-obj.o -MD -MP -MF .deps/libdl_a-rtl-obj.Tpo -c -o libdl_a-rtl-obj.o `test -f 'rtl-obj.c' || echo '../../../../../../rtems/c/src/../../cpukit/libdl/'`rtl-obj.c 0x70a8b5 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc-4.9.1/gcc/rtl-error.c:109 0x70a8e9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc-4.9.1/gcc/rtl-error.c:117 0x93096e insn_default_length(rtx_def*) /users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/lm32-rtems4.11-gcc-4.9.1-newlib-19-Aug-2014-1/build/gcc/insn-attrtab.c:143 Would it pay to check 4.9.2 and the latest newlib first ? Chris 0x595e8a shorten_branches(rtx_def*) ../../gcc-4.9.1/gcc/final.c:1191 0x5962ef rest_of_handle_shorten_branches ../../gcc-4.9.1/gcc/final.c:4519 0x5962ef execute ../../gcc-4.9.1/gcc/final.c:4548 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] (2 commits squashed into one) Beagle BSP for review
Good idea, I did it.
On Mon, Nov 3, 2014 at 10:32 PM, Gedare Bloom ged...@rtems.org wrote:
Please send a note to rtems-users, some may be interested to hear this
addition. -Gedare
On Mon, Nov 3, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com wrote:
Indeed. I did right away verify I can build run test everything for
the
beaglebones and the bbxm from mainline. So that seems to have gone fine.
The supporting tools and RSB stuff I am in contact with Chris about.
On Mon, Nov 3, 2014 at 10:23 PM, Joel Sherrill
joel.sherr...@oarcorp.com
wrote:
On 11/3/2014 3:06 PM, Ben Gras wrote:
All,
Joel merged these and I updated my blog post to reflect the mainline
repo.
Thanks Joel!
Thank you Ben for the nice submission!!!
Now to make sure it is reproducible from here and we have merged
all the bits into the tools, etc.
On Mon, Nov 3, 2014 at 8:40 PM, Ben Gras b...@shrike-systems.com
wrote:
All,
I have new patches with some last-minute smoothings added; removed
obsolete beagle.cfg, TODO, and separated the more generic ARM headers
into a
separate commit. The new 3 commits are attached (and in my RTEMS github
repo).
Gedare, there is also a diff w.r.t. the previous submission attached as
requested.
On Mon, Nov 3, 2014 at 3:01 PM, Gedare Bloom ged...@rtems.org wrote:
Hi,
I don't have time to review, but am OK in principle with committing
this code as it is tested, with the caveat that my previous comments
be addressed post-merge.
If you have a diff / commits on top of what you sent before, I'd be
glad to give those a quick look.
Thanks for your contribution!
Gedare
On Mon, Nov 3, 2014 at 7:20 AM, Ben Gras b...@shrike-systems.com
wrote:
All,
Ok, as promised, I rebased and re-tested and have found included a
portable way of making the SD card image (included in sdcard.sh), to
be
merged with RSB (i.e. some of the tools sdcard.sh relies on are
missing in
mainline RSB). Some of Gedare's initial feedback is processed thanks
to
Brandon Matthews. It's tested to run on the original beaglebone,
beaglebone
black and qemu linaro. (The assumption is it'll run on the bbxm
hardware as
well as it was before rebasing.)
The result is split into 2 patches to show what was Claas's initial
work.
This makes them a bit unreadable for the final result from the
patches
unfortunately.
As before, see
http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
on how to build all the tools, RTEMS executables, sdcard images, and
run the
test set from linaro qemu.
On Sat, Aug 30, 2014 at 5:50 PM, Ben Gras b...@shrike-systems.com
wrote:
All,
OK, that seems like a fruitful way to proceed to me.
Then I will do some minor cleanups, rebase, do all the tests again,
and
re-submit. There's just one problem I know of that I want to fix
before the
first commit happens, and that is that the FAT fs made by mtools
doesn't
boot on the HW it seems. (It does on the emulator.) A last-minute
change -
switching to mtools instead of dosfstools to use to make the SD
card
image
because the latter is so linux-only.
Stay tuned.
On Wed, Aug 20, 2014 at 4:20 PM, Gedare Bloom ged...@rtems.org
wrote:
Ben, As far as getting this merged, all of my comments can be done
as
a follow-on commit. -Gedare
On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras
b...@shrike-systems.com
wrote:
Thanks for the fast detailed review. Let me get back to
it/you.
In the meantime, any other feedback? From anyone I mean.
On Thu, Jul 24, 2014 at 4:45 PM, Gedare Bloom ged...@rtems.org
wrote:
Hi Ben,
Great work. I have a few comments. I skipped the i2c.h and
i2c.c
files. Most of my comments are about style and a few requests
to
refactor some of the larger files. The refactoring can be added
to
your TODO if you like. Please fix the style issues if it is
not a
burden.
+++ b/c/src/lib/libbsp/arm/beagle/README
+$ ../claas-rtems/configure --target=arm-rtems4.11
--enable-rtemsbsp=beaglebonewhite beagleboardxm
Replace claas-rtems with rtems. If RSB support is available,
make
a
note about it.
+++ b/c/src/lib/libbsp/arm/beagle/TODO
[...]
open:
+ . how to handle the interrupt?
What does this mean?
+++ b/c/src/lib/libbsp/arm/beagle/clock.c
Why is the entire file ifdef'd on ARM_MULTILIB_ARCH_V4?
It might be sensible to put the struct definitions in a .h file
if
these omap registers might be re-usable.
+static struct omap_timer_registers regs_v2 = {
This might be better to put behind an #if IS_AM335X since it is
not
used otherwise?
+
+
+
Avoid more than one blank line in a row.
Re: m32c libdl build error
On November 3, 2014 3:39:13 PM CST, Chris Johns chr...@rtems.org wrote: On 4/11/2014 8:30 am, Joel Sherrill wrote: On 11/3/2014 3:29 PM, Chris Johns wrote: On 4/11/2014 8:26 am, Joel Sherrill wrote: Hi Looks like a Makefile/configure issue. Seems so. There is no relocation code for m32c. There is for m32r. Got a quick fix? This looks like the easiest of the failures so far. :( I checked the lists on cpukit/configure.ac and libtest/configure.ac and m32c is not listed and so LIBDL empties the Makefile. Does this mean a dummy preinstall target is needed ? I guess so. This stuff is magic. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtl-elf.c does not compile for mips
Hi Another architecture specific issue: mips-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../jmr3904/lib/include -DRTEMS_RTL_RAP_LOADER=1 -DRTEMS_RTL_ELF_LOADER=1 -march=r3900 -Wa,-xgot -G0 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libdl_a-rtl-elf.o -MD -MP -MF .deps/libdl_a-rtl-elf.Tpo -c -o libdl_a-rtl-elf.o `test -f 'rtl-elf.c' || echo '../../../../../../rtems/c/src/../../cpukit/libdl/'`rtl-elf.c In file included from /users/joel/rtems-4.11-work/tools/mips-rtems4.11/include/sys/_default_fcntl.h:8:0, from /users/joel/rtems-4.11-work/tools/mips-rtems4.11/include/sys/fcntl.h:3, from /users/joel/rtems-4.11-work/tools/mips-rtems4.11/include/fcntl.h:1, from ../../../../../../rtems/c/src/../../cpukit/libdl/rtl-elf.c:23: ../../../../../../rtems/c/src/../../cpukit/libdl/rtl-elf.c: In function 'rtems_rtl_elf_machine_check': ../../cpukit/../../../jmr3904/lib/include/sys/exec_elf.h:54:31: error: 'ELF32_MACHDEP_ID_CASES' undeclared (first use in this function) #define ELFDEFNNAME(x) CONCAT(ELF,CONCAT(ELFSIZE,CONCAT(_,x))) ^ ../../cpukit/../../../jmr3904/lib/include/sys/exec_elf.h:54:24: note: in expansion of macro 'CONCAT' #define ELFDEFNNAME(x) CONCAT(ELF,CONCAT(ELFSIZE,CONCAT(_,x))) ^ ../../../../../../rtems/c/src/../../cpukit/libdl/rtl-elf.c:59:5: note: in expansion of macro 'ELFDEFNNAME' ELFDEFNNAME (MACHDEP_ID_CASES) -- 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: m32c libdl build error
On 11/3/2014 3:30 PM, Joel Sherrill wrote: On 11/3/2014 3:29 PM, Chris Johns wrote: On 4/11/2014 8:26 am, Joel Sherrill wrote: Hi Looks like a Makefile/configure issue. Seems so. There is no relocation code for m32c. There is for m32r. Got a quick fix? This looks like the easiest of the failures so far. :( This happened also on the sparc64. I have a fix for it and will commit all my fixes after the long build finishes. It is about 2/3 finished now. --joel Chris gmake[6]: Entering directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-m32c-m32csim-rtems/m32c-rtems4.11/c/m32csim/cpukit/libdl' gmake[6]: *** No rule to make target `preinstall'. Stop. gmake[6]: Leaving directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-m32c-m32csim-rtems/m32c-rtems4.11/c/m32csim/cpukit/libdl' gmake[5]: *** [preinstall-recursive] Error 1 -- 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: dl01 failure on i386/pc386
On November 3, 2014 6:06:37 PM CST, Chris Johns chr...@rtems.org wrote: On 4/11/2014 10:57 am, Joel Sherrill wrote: On 11/3/2014 3:22 PM, Joel Sherrill wrote: Hi rtems-syms -e -c -mtune=i386 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -o dl-sym.o dl01.pre.exe /tmp/ccobfWoY.s: Assembler messages: /tmp/ccobfWoY.s:2196: Error: unrecognized symbol type /tmp/ccobfWoY.s:2200: Error: unrecognized symbol type error: compiling wrapper: Compiler error gmake[7]: *** [dl-sym.o] Error 10 gmake[7]: Leaving directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-i386-pc386-rtems/i386-rtems4.11/c/pc386/testsuites/libtests/dl01' All i386, PowerPC and bfin BSPs fail this way. I will take a look. Just fixing the ARM issue Peng reported. The bfin requires an uncommitted patch to get this far. This looks like a pretty generic bug. What patch is this ? Moving the endif ahead of the include statements in the libdl/Makefile.am. let's m32c and bfin get farther. Also bfin specific file did not have the subdirectory on the rtl.h include. Focus on this and I week dig through the kids and commit odd patches tomorrow. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTL arm load failed
On 2/11/2014 8:28 pm, Peng Fan wrote: Hi, qemu-system-arm -no-reboot -net none -nographic -M realview-pbx-a9 -m 256M -kernel `find . -name dl01.exe` -s -S *** BEGIN OF TEST libdl (RTL) Loader 1 *** load: /dl-o1.o rtl: unsupported section: 15: type=1879048195 flags=00 handle: 0x212b10 has unresolved externals Fixed on head ... $ qemu-system-arm -no-reboot -net none -monitor none -serial stdio -nographic -M realview-pbx-a9 -m 256M -kernel `find . -name dl01.exe` *** BEGIN OF TEST libdl (RTL) Loader 1 *** load: /dl-o1.o handle: 0x2137d8 loaded Loaded module: argc:2 [../../../../../../../../rtems.master/c/src/../../testsuites/libtests/dl01/dl-o1.c] 0: Line 1 1: Line 2 Loaded module: argc:3 [../../../../../../../../rtems.master/c/src/../../testsuites/libtests/dl01/dl-o1.c] 0: Call 2, line 1 1: Call 2, line 2 2: Call 2, line 3 handle: 0x2137d8 closed *** END OF TEST libdl (RTL) Loader 1 *** Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
