date:20160104

Re: Fwd: Windows 10 Build

2016-01-04 Thread Sebastian Huber


Hello Owen,

this page contains out of date information. Use the RSB to create a tool 
chain for MinGW and use msys2. I currently don't have time to document 
the steps, but it works quite well with msys2.


On 30/12/15 01:27, Owen Pan wrote:


Hi all,

I am trying to bootstrap RTEMS on Windows 10 with MinGW and MSYS, 
following 
https://devel.rtems.org/wiki/TBR/UserManual/MinGW_Tools_for_Windows. 
However, I get the following: http://pastebin.com/yFLfYMzc. Does 
anyone know how to fix this?


Thanks,

Owen




___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


--
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: Ticker interrupt priority

2016-01-04 Thread Sebastian Huber


On 28/12/15 19:14, Martin Galvan wrote:

Hi everyone! We're still looking into the issue Marcos described here:

https://lists.rtems.org/pipermail/devel/2015-December/013216.html

We noticed the problem seems to go away if we set the ticker interrupt
priority to be the same as for the other interrupts. While that's not
a definitive fix, I was wondering if anyone knows why is it necessary
that the ticker interrupt has a lower priority than the rest.


Its not necessary, but in most cases it is desirable since the system 
tick is not related to a low-latency hardware event.


--
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: Problem with system time in lpc176x bsp

2016-01-04 Thread Sebastian Huber




On 23/12/15 22:22, Marcos Díaz wrote:

That patch didn't work,
one reason is that it has a mistake:
in kern_tc.c you defined this macro:

#define _Timecounter_Release(lock_context) \
+ *_ISR_lock_ISR_disable_and_acquire*(&_Timecounter_Lock, lock_context)

I think you meant:

*_ISR_lock_Release_and_ISR_enable*(&_Timecounter_Lock, lock_context)


Its strange, that this didn't lead to failures in Qemu.



The other reason is that as I said, the driver checks for the flag 
PENDSTSET of the ICSR register, and I think this approach is wrong, 
because that flag goes down when the tick interrupt is attended. I 
used the solution I proposed before, but I'm still seeing some errors. 
I'll let you know what I find.


Would you mind testing the attached second version of the patch?

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

>From fc52281c3c434f66d5765e9282d3c1a98e0b8447 Mon Sep 17 00:00:00 2001
From: Sebastian Huber 
Date: Wed, 23 Dec 2015 07:29:47 +0100
Subject: [PATCH v2] score: Fix simple timecounter support

Close #2502.
---
 .../arm/shared/armv7m/clock/armv7m-clock-config.c  | 45 +++---
 c/src/lib/libbsp/shared/clockdrv_shell.h   | 16 +++-
 cpukit/rtems/src/clocktick.c   |  6 ++-
 cpukit/sapi/include/rtems/timecounter.h| 35 ++---
 cpukit/score/include/rtems/score/timecounter.h | 27 -
 cpukit/score/src/kern_tc.c | 16 
 doc/bsp_howto/clock.t  | 13 ++-
 7 files changed, 125 insertions(+), 33 deletions(-)

diff --git a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
index e78684c..f5bd9ac 100644
--- a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
+++ b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
@@ -23,7 +23,12 @@
 /* This is defined in clockdrv_shell.h */
 static void Clock_isr(void *arg);
 
-static rtems_timecounter_simple _ARMV7M_TC;
+typedef struct {
+  rtems_timecounter_simple base;
+  bool countflag;
+} ARMV7M_Timecounter;
+
+static ARMV7M_Timecounter _ARMV7M_TC;
 
 static uint32_t _ARMV7M_TC_get(rtems_timecounter_simple *tc)
 {
@@ -32,11 +37,19 @@ static uint32_t _ARMV7M_TC_get(rtems_timecounter_simple *tc)
   return systick->cvr;
 }
 
-static bool _ARMV7M_TC_is_pending(rtems_timecounter_simple *tc)
+static bool _ARMV7M_TC_is_pending(rtems_timecounter_simple *base)
 {
-  volatile ARMV7M_SCB *scb = _ARMV7M_SCB;
+  ARMV7M_Timecounter *tc = (ARMV7M_Timecounter *) base;
+  bool countflag = tc->countflag;
+
+  if (!countflag) {
+volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
 
-  return ((scb->icsr & ARMV7M_SCB_ICSR_PENDSTSET) != 0);
+countflag = ((systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) != 0);
+tc->countflag = countflag;
+  }
+
+  return countflag;
 }
 
 static uint32_t _ARMV7M_TC_get_timecount(struct timecounter *tc)
@@ -48,19 +61,26 @@ static uint32_t _ARMV7M_TC_get_timecount(struct timecounter *tc)
   );
 }
 
-static void _ARMV7M_TC_tick(void)
-{
-  rtems_timecounter_simple_downcounter_tick(&_ARMV7M_TC, _ARMV7M_TC_get);
-}
-
-static void _ARMV7M_Systick_at_tick(void)
+static void _ARMV7M_TC_at_tick(rtems_timecounter_simple *base)
 {
+  ARMV7M_Timecounter *tc = (ARMV7M_Timecounter *) base;
   volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
 
+  tc->countflag = false;
+
   /* Clear COUNTFLAG */
   systick->csr;
 }
 
+static void _ARMV7M_TC_tick(void)
+{
+  rtems_timecounter_simple_downcounter_tick(
+&_ARMV7M_TC.base,
+_ARMV7M_TC_get,
+_ARMV7M_TC_at_tick
+  );
+}
+
 static void _ARMV7M_Systick_handler(void)
 {
   _ARMV7M_Interrupt_service_enter();
@@ -95,7 +115,7 @@ static void _ARMV7M_Systick_initialize(void)
 | ARMV7M_SYSTICK_CSR_CLKSOURCE;
 
   rtems_timecounter_simple_install(
-&_ARMV7M_TC,
+&_ARMV7M_TC.base,
 freq,
 interval,
 _ARMV7M_TC_get_timecount
@@ -111,9 +131,6 @@ static void _ARMV7M_Systick_cleanup(void)
 
 #define Clock_driver_timecounter_tick() _ARMV7M_TC_tick()
 
-#define Clock_driver_support_at_tick() \
-  _ARMV7M_Systick_at_tick()
-
 #define Clock_driver_support_initialize_hardware() \
   _ARMV7M_Systick_initialize()
 
diff --git a/c/src/lib/libbsp/shared/clockdrv_shell.h b/c/src/lib/libbsp/shared/clockdrv_shell.h
index d546fb8..96b962f 100644
--- a/c/src/lib/libbsp/shared/clockdrv_shell.h
+++ b/c/src/lib/libbsp/shared/clockdrv_shell.h
@@ -44,6 +44,13 @@
   #define Clock_driver_support_find_timer()
 #endif
 
+/**
+ * @brief Do nothing by default.
+ */
+#ifndef Clock_driver_support_at_tick
+  #define Clock_driver_support_at_tick()
+#endif
+
 /*
  * A specialized clock driver may use for example rtems_time

[PATCH 2/2] linkers: Fix for targets with a small-data area

2016-01-04 Thread Sebastian Huber

---
 linkers/rtems-syms.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/linkers/rtems-syms.cpp b/linkers/rtems-syms.cpp
index 97315ac..f0ffe94 100644
--- a/linkers/rtems-syms.cpp
+++ b/linkers/rtems-syms.cpp
@@ -60,7 +60,7 @@ static const char* c_header[] =
   " */",
   "",
   "extern const unsigned char rtems__rtl_base_globals[];",
-  "extern const unsigned int rtems__rtl_base_globals_size;",
+  "extern const unsigned int rtems__rtl_base_globals_size[];",
   "",
   "void rtems_rtl_base_sym_global_add (const unsigned char* , unsigned int );",
   "",
@@ -105,7 +105,7 @@ static const char* c_rtl_call_body[] =
 {
   "{",
   "  rtems_rtl_base_sym_global_add (&rtems__rtl_base_globals[0],",
-  " rtems__rtl_base_globals_size);",
+  " rtems__rtl_base_globals_size[0]);",
   "}",
   0
 };
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/2] linkers: Avoid cast

2016-01-04 Thread Sebastian Huber

---
 linkers/rtems-syms.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linkers/rtems-syms.cpp b/linkers/rtems-syms.cpp
index c8f54ae..97315ac 100644
--- a/linkers/rtems-syms.cpp
+++ b/linkers/rtems-syms.cpp
@@ -104,7 +104,7 @@ static const char* c_trailer[] =
 static const char* c_rtl_call_body[] =
 {
   "{",
-  "  rtems_rtl_base_sym_global_add ((const unsigned char*) 
&rtems__rtl_base_globals,",
+  "  rtems_rtl_base_sym_global_add (&rtems__rtl_base_globals[0],",
   " rtems__rtl_base_globals_size);",
   "}",
   0
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libnetworking/rtems_dhcp.c: Fix invariant DHCP transaction IDs.

2016-01-04 Thread Sebastian Huber

The rand() function doesn't produce a client specific random number.  
Its not clear to me how the bug is actually addressed.


On 28/12/15 19:23, Aun-Ali Zaidi wrote:

From: Tim Cussins 

The DHCP code in rtems uses an unchanging transaction id (xid) in the dhcp 
discover and request
packets.

It is possible (and in fact has been observed) that DHCP servers may issue 
multiple OFFER packets
in response to multiple REQUEST packets from the same device.

The second OFFER packet could potentially be received while the DHCP state 
machine is waiting for
an ACK packet - and this would cause the rtems dhcp process to fail needlessly.

A solution to this is to use the transaction id field (described in the 
bootp/dhcp protocols) to
match server DHCP replies with rtems dhcp requests.

Excerpt from RFC 2131:

4.4.1 Initialization and allocation of network address

..

The client generates and records a random transaction identifier and
inserts that identifier into the 'xid' field.  The client records its
own local time for later use in computing the lease expiration.  The
client then broadcasts the DHCPDISCOVER on the local hardware
broadcast address to the 0x IP broadcast address and 'DHCP
server' UDP port.

If the 'xid' of an arriving DHCPOFFER message does not match the
'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
must be silently discarded.  Any arriving DHCPACK messages must be
silently discarded.

..

The patch creates a unique xid for each dhcp transaction: the DISCOVER/OFFER 
and REQUEST/ACK
phases use different xid's, there is no confusion in the rtems state machine.

As bootpc_call() checks the xid of the BOOTREPLY, using a new xid prevents 
packets related to
the previous transaction (DISCOVER/OFFER) from being accepted by bootpc_call().

closes #1406.
---
  cpukit/libnetworking/rtems/rtems_dhcp.c | 12 +---
  1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/cpukit/libnetworking/rtems/rtems_dhcp.c 
b/cpukit/libnetworking/rtems/rtems_dhcp.c
index cb6966d..144de17 100644
--- a/cpukit/libnetworking/rtems/rtems_dhcp.c
+++ b/cpukit/libnetworking/rtems/rtems_dhcp.c
@@ -518,8 +518,7 @@ process_options (unsigned char *optbuf, int optbufSize)
   */
  static int
  dhcp_discover_req (struct dhcp_packet* call,
-   struct sockaddr_dl *sdl,
-   unsigned long *xid)
+   struct sockaddr_dl *sdl)
  {
int len = 0;
  
@@ -532,8 +531,7 @@ dhcp_discover_req (struct dhcp_packet* call,

call->htype = 1; /* 10mb ethernet */
call->hlen = sdl->sdl_alen;   /* Hardware address length */
call->hops = 0;
-  (*xid)++;
-  call->xid = htonl (*xid);
+  call->xid = htonl (ntohl(call->xid) + rand());
call->flags = htons (DHCP_BROADCAST);
  
memcpy (&call->chaddr, LLADDR (sdl), sdl->sdl_alen);

@@ -612,7 +610,7 @@ dhcp_request_req (struct dhcp_packet* call,
call->htype = 1; /* 10mb ethernet */
call->hlen = sdl->sdl_alen;   /* Hardware address length */
call->hops = 0;
-  call->xid = reply->xid;
+  call->xid = reply->xid = htonl (ntohl(call->xid) + rand());
if (broadcast)
  call->flags = htons (DHCP_BROADCAST);
else
@@ -891,7 +889,6 @@ dhcp_init (int update_files)
  {
struct dhcp_packet   call;
struct dhcp_packet   reply;
-  static unsigned long xid = ~0xFF;
struct ifreq ireq;
struct ifnet *ifp;
struct socket*so;
@@ -959,7 +956,8 @@ dhcp_init (int update_files)
/*
 * Build the DHCP Discover
 */
-  dhcp_discover_req (&call, sdl, &xid);
+  call.xid = htons (rand());
+  dhcp_discover_req (&call, sdl);
  
/*

 * Send the Discover.


--
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] libnetworking/rtems_dhcp.c: Fix improper hostname handling in DHCP request

2016-01-04 Thread Sebastian Huber




On 27/12/15 23:43, Aun-Ali Zaidi wrote:

From: Tim Cussins 

DHCP requests add the hostname option in dhcp_request_req() - this is cool, 
except that the dhcp
spec requires that this option has a length >= 1 char.

Excerpt taken from RFC 2132:

3.14. Host Name Option

This option specifies the name of the client.  The name may or may
not be qualified with the local domain name (see section 3.17 for the
preferred way to retrieve the domain name).  See RFC 1035 for
character set restrictions.

The code for this option is 12, and its minimum length is 1.

 Code   Len Host Name
+-+-+-+-+-+-+-+-+--
|  12 |  n  |  h1 |  h2 |  h3 |  h4 |  h5 |  h6 |  ...
+-+-+-+-+-+-+-+-+--

At present, the hostname is added regardless. This appears to trigger a bug in 
a specific Netgear
router that causes it's dhcp process to lock up.

closes #1405.
---
  cpukit/libnetworking/rtems/rtems_dhcp.c | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/cpukit/libnetworking/rtems/rtems_dhcp.c 
b/cpukit/libnetworking/rtems/rtems_dhcp.c
index cb6966d..5b8fe32 100644
--- a/cpukit/libnetworking/rtems/rtems_dhcp.c
+++ b/cpukit/libnetworking/rtems/rtems_dhcp.c
@@ -681,10 +681,18 @@ dhcp_request_req (struct dhcp_packet* call,
{
  if (gethostname (hostname, MAXHOSTNAMELEN) == 0)
  {
-  call->vend[len++] = DHCP_HOST;
-  call->vend[len++] = strlen (hostname);
-  strcpy ((char*) &call->vend[len], hostname);
-  len += strlen (hostname);
+  /* RFC 2132 Section 3.14 dictates min length for this option is 1 char.
+ If hostname is zero-length, then let's just not add it */
+
+  int hostnamelen = strlen(hostname);


The return type of strlen() is size_t. Incorrect style for this 
function, use strlen (hostname).



+
+  if ( (hostnamelen > 0) && (hostnamelen < 256) )


Superfluous parenthesis.


+  {
+call->vend[len++] = DHCP_HOST;
+   call->vend[len++] = (uint8_t) hostnamelen;
+   strcpy ((char *) &call->vend[len], hostname);


Better use memcpy() if you already know the length of the string.


+   len += hostnamelen;
+  }
  }
  free (hostname, 0);
}


--
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] libnetworking/rtems_dhcp.c: Fix improper hostname handling in DHCP request

2016-01-04 Thread Sebastian Huber

On 04/01/16 12:55, Daniel Gutson wrote:

>
>> +
>> +  if ( (hostnamelen > 0) && (hostnamelen < 256) )

Avoid magic numbers. Should this be MAXHOSTNAMELEN, and in any case ot 
has been already limited before in the call to gethosname turning the 
check unnecessary? (Don't believe me, please verify).

I think this should be UINT8_MAX, since it is later stored as an uint8_t.

--
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 2/2] linkers: Fix for targets with a small-data area

2016-01-04 Thread Joel Sherrill

What exactly does this fix and how does it fix it?

--joel

On Mon, Jan 4, 2016 at 4:16 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  linkers/rtems-syms.cpp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/linkers/rtems-syms.cpp b/linkers/rtems-syms.cpp
> index 97315ac..f0ffe94 100644
> --- a/linkers/rtems-syms.cpp
> +++ b/linkers/rtems-syms.cpp
> @@ -60,7 +60,7 @@ static const char* c_header[] =
>" */",
>"",
>"extern const unsigned char rtems__rtl_base_globals[];",
> -  "extern const unsigned int rtems__rtl_base_globals_size;",
> +  "extern const unsigned int rtems__rtl_base_globals_size[];",
>"",
>"void rtems_rtl_base_sym_global_add (const unsigned char* , unsigned
> int );",
>"",
> @@ -105,7 +105,7 @@ static const char* c_rtl_call_body[] =
>  {
>"{",
>"  rtems_rtl_base_sym_global_add (&rtems__rtl_base_globals[0],",
> -  " rtems__rtl_base_globals_size);",
> +  " rtems__rtl_base_globals_size[0]);",
>"}",
>0
>  };
> --
> 1.8.4.5
>
> ___
> 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: Problem with system time in lpc176x bsp

2016-01-04 Thread Joel Sherrill

On Mon, Jan 4, 2016 at 3:48 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 23/12/15 22:22, Marcos Díaz wrote:
>
>> That patch didn't work,
>> one reason is that it has a mistake:
>> in kern_tc.c you defined this macro:
>>
>> #define _Timecounter_Release(lock_context) \
>> + *_ISR_lock_ISR_disable_and_acquire*(&_Timecounter_Lock, lock_context)
>>
>> I think you meant:
>>
>> *_ISR_lock_Release_and_ISR_enable*(&_Timecounter_Lock, lock_context)
>>
>
> Its strange, that this didn't lead to failures in Qemu.
>
>
Qemu doesn't do cycle or instruction level simulation. It does blocks of
instructions between potential control flow points. Perhaps this is enough
to make real hardware and the simulation behave differently in this case.

For sure, it reduces the potential race conditions showing up in SMP
applications since it is alternating blocks of instructions on each
simulated core.


>
>> The other reason is that as I said, the driver checks for the flag
>> PENDSTSET of the ICSR register, and I think this approach is wrong, because
>> that flag goes down when the tick interrupt is attended. I used the
>> solution I proposed before, but I'm still seeing some errors. I'll let you
>> know what I find.
>>
>
> Would you mind testing the attached second version of the patch?
>
> --
> 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Removing Architectures Patches

2016-01-04 Thread Joel Sherrill

Hi

I think I cleaned everything up and did grep's after each architecture to
make sure it was gone except for standard GNU files.

That said, I could easily have made a mistake. If anyone spots anything
questionable, please speak up.

FWIW there are other repos which need to be swept. These patches just cover
the core RTEMS repository. Even rtems-libbsd needs a sweep.

[joel@localhost rtems-libbsd]$ find . -name avr -o -name m32r -o -name h8300
./freebsd/sys/avr
./freebsd/sys/avr/avr
./freebsd/sys/m32r
./freebsd/sys/m32r/m32r
./freebsd/sys/h8300
./freebsd/sys/h8300/h8300

The tool targets are last but I am going to start the process on that
upstream.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Many BSPs Fail to link CXX tests

2016-01-04 Thread Joel Sherrill

On Sun, Jan 3, 2016 at 11:00 PM, Gedare Bloom  wrote:

> On Sun, Jan 3, 2016 at 9:47 PM, Joel Sherrill  wrote:
> >
> >
> > On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns  wrote:
> >> Can you get a suitable list of functions that must be present in the
> >> executable and check they are present with nm?
> >>
> >
> > It should be simple if the breakage is between the entry point and the
> rest
> > of the BSP. If hello does not include bsp_start() or
> > rtems_initialize_data_structures(), then it is known to be broken. This
> is
> > what broke on sis -- the first 16 instructions of the start code had no
> > dependency on anything else. So the linkages were satisfied and nothing
> else
> > pulled in. :)
> >
> Such a list should be easy enough to create by building every BSP and
> creating a list of functions appearing in every one (known to run).
>
>
The scripts in rtems-testing/rtems keep a copy of ticker.ralf named
CPU-BSP-ticker.ralf. For the ones I had laying around that were actually
in ELF format with symbols still, there were 362 symbols which showed
up in 68 files (that appears to be the magic maximum number).

file *.ralf | grep ELF | cut -d':' -f1 | while read f
do
  target=`echo $f | cut -d'-' -f1`
  mynm=${target}rtems4.12-nm

  nm -g ${f} | grep " T " | cut -d' ' -f3
done | sort | uniq -c | sort -n

There is no guarantee that those 362 symbols are actually really required
and turning on per-item section linking I hope would reduce that. Perhaps
a core list of BSP init, RTEMS init, application, and C library referenced
would be sufficient. For ticker or hello, this would be:

boot_card()
bsp_start()
rtems_initialize_data_structures()
Init()

If you managed to link enough to include Init() and this broke the
executable,
then I would expect a very subtle problem that nothing automated will find.
Something like leaving out interrupt vectors which we wouldn't be looking
for.

I am not even sure about printf() since gcc optimizes constant string prints
to puts() and the tests can be configured to use printk().

Any thoughts?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] linkers: Fix for targets with a small-data area

2016-01-04 Thread Sebastian Huber



- Am 4. Jan 2016 um 18:01 schrieb Joel Sherrill j...@rtems.org:

> What exactly does this fix and how does it fix it?

I will add this to the commit message:

On certain targets (e.g. PowerPC) global data below a certain threshold (e.g. 8 
bytes) may resided in a special memory area, the small-data area.  This allows 
more efficient load/store operations.  Placing such data into the wrong section 
(e.g. .rodata) leads to relocation errors during link-time.  See test program 
libtests/dl02 in the RTEMS testsuite.  Using an array of unspecified size 
prevents that the compiler assumes that a certain variable is in the small-data 
area.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] linkers: Fix for targets with a small-data area

2016-01-04 Thread Joel Sherrill

On Mon, Jan 4, 2016 at 12:58 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> - Am 4. Jan 2016 um 18:01 schrieb Joel Sherrill j...@rtems.org:
>
> > What exactly does this fix and how does it fix it?
>
> I will add this to the commit message:
>
> On certain targets (e.g. PowerPC) global data below a certain threshold
> (e.g. 8 bytes) may resided in a special memory area, the small-data area.
> This allows more efficient load/store operations.  Placing such data into
> the wrong section (e.g. .rodata) leads to relocation errors during
> link-time.  See test program libtests/dl02 in the RTEMS testsuite.  Using
> an array of unspecified size prevents that the compiler assumes that a
> certain variable is in the small-data area.
>

Thanks. I trusted you that it was an improvement.. Just didn't know how. :)

The small data area can be a pain. On the MIPS, there is a GCC flag to
control the maximum size of a data item allowed to be placed in it.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Problem with system time in lpc176x bsp

2016-01-04 Thread Daniel Gutson

On Mon, Jan 4, 2016 at 2:04 PM, Joel Sherrill  wrote:

>
>
> On Mon, Jan 4, 2016 at 3:48 AM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>>
>>
>> On 23/12/15 22:22, Marcos Díaz wrote:
>>
>>> That patch didn't work,
>>> one reason is that it has a mistake:
>>> in kern_tc.c you defined this macro:
>>>
>>> #define _Timecounter_Release(lock_context) \
>>> + *_ISR_lock_ISR_disable_and_acquire*(&_Timecounter_Lock, lock_context)
>>>
>>> I think you meant:
>>>
>>> *_ISR_lock_Release_and_ISR_enable*(&_Timecounter_Lock, lock_context)
>>>
>>
>> Its strange, that this didn't lead to failures in Qemu.
>>
>>
> Qemu doesn't do cycle or instruction level simulation.
>

I'm not sure if I fully understand this statement, but FWIW qemu can do
per-instruction emulation, in fact I fixed one 7 years ago
https://lists.nongnu.org/archive/html/qemu-devel/2009-08/msg01153.html


> It does blocks of instructions between potential control flow points.
> Perhaps this is enough to make real hardware and the simulation behave
> differently in this case.
>
> For sure, it reduces the potential race conditions showing up in SMP
> applications since it is alternating blocks of instructions on each
> simulated core.
>
>
>>
>>> The other reason is that as I said, the driver checks for the flag
>>> PENDSTSET of the ICSR register, and I think this approach is wrong, because
>>> that flag goes down when the tick interrupt is attended. I used the
>>> solution I proposed before, but I'm still seeing some errors. I'll let you
>>> know what I find.
>>>
>>
>> Would you mind testing the attached second version of the patch?
>>
>> --
>> 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
>>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Rtems-testing bsp add

2016-01-04 Thread Aurelio Remonda

Hi, i run some tests with do_one script on realview_pbx_a9_qemu
several months ago. I was wondering: how simple is to add a new bsp
for example i would like to run tests for Stellaris lm3s6965 (which is
supported by qemu).
-Is this just configuration and adding a simple exp file?
-I just need to modify rtems-testing code or rtems code as well?

If im wrong with this approach please let me know, or if someone can
give me some hints i will be glad to add this bsp.
Thank you in advance.

-- 
Aurelio Remonda

Software Engineer

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54-351-4217888 / 4218211
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: Windows 10 Build

2016-01-04 Thread Chris Johns


On 01/04/16 20:10, Sebastian Huber wrote:


this page contains out of date information.


I agree.


Use the RSB to create a tool
chain for MinGW and use msys2. I currently don't have time to document
the steps, but it works quite well with msys2.


There is an active GCI task about this which is being worked on.

I am hoping to get to the clean up task and get a single up to date wiki 
page.


Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] linkers: Fix for targets with a small-data area

2016-01-04 Thread Chris Johns


On 01/05/16 05:58, Sebastian Huber wrote:



- Am 4. Jan 2016 um 18:01 schrieb Joel Sherrill j...@rtems.org:


What exactly does this fix and how does it fix it?


I will add this to the commit message:

On certain targets (e.g. PowerPC) global data below a certain threshold (e.g. 8 
bytes) may resided in a special memory area, the small-data area.  This allows 
more efficient load/store operations.  Placing such data into the wrong section 
(e.g. .rodata) leads to relocation errors during link-time.  See test program 
libtests/dl02 in the RTEMS testsuite.  Using an array of unspecified size 
prevents that the compiler assumes that a certain variable is in the small-data 
area.


Looks good with the updated commit message. Thanks.

Chris

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RSB rtems-4.12 gcc-6 dependent package version numbers.

2016-01-04 Thread Chris Johns


Hi Sebastian,

Looking at 4.12 build in the RSB I see:

 mpfr   2.4.2
 mpc0.8.1
 gmp4.3.2

The 4.11 gcc-4.9.3 is using:

 mpfr   3.0.1
 mpc0.8.2
 gmp5.0.5

4.12/rtems-arm builds on FreeBSD.

Ok to update to the 4.11 versions?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

psim ticker size difference with per-element sections

2016-01-04 Thread Joel Sherrill

Hi

This is before and after for ticker.

  text   databssdechex filename
 169644   2260 16605288 16777192 e8
ticker-executables-before/powerpc-psim-ticker.ralf
 127352   2216 16647628 16777196 ec
ticker-executables/powerpc-psim-ticker.ralf

That is a pretty sizable drop (25%) and it still runs just fine.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB rtems-4.12 gcc-6 dependent package version numbers.

2016-01-04 Thread Sebastian Huber


Hello Chris,

I used the versions of the contrib/download_prerequisites script of the GCC.

On 05/01/16 00:23, Chris Johns wrote:

Hi Sebastian,

Looking at 4.12 build in the RSB I see:

 mpfr2.4.2
 mpc0.8.1
 gmp4.3.2

The 4.11 gcc-4.9.3 is using:

 mpfr3.0.1
 mpc0.8.2
 gmp5.0.5

4.12/rtems-arm builds on FreeBSD.

Ok to update to the 4.11 versions?

Chris


--
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: Fwd: Windows 10 Build

Re: Ticker interrupt priority

Re: Problem with system time in lpc176x bsp

[PATCH 2/2] linkers: Fix for targets with a small-data area

[PATCH 1/2] linkers: Avoid cast

Re: [PATCH] libnetworking/rtems_dhcp.c: Fix invariant DHCP transaction IDs.

Re: [PATCH] libnetworking/rtems_dhcp.c: Fix improper hostname handling in DHCP request

Re: [PATCH] libnetworking/rtems_dhcp.c: Fix improper hostname handling in DHCP request

Re: [PATCH 2/2] linkers: Fix for targets with a small-data area

Re: Problem with system time in lpc176x bsp

Removing Architectures Patches

Re: Many BSPs Fail to link CXX tests

Re: [PATCH 2/2] linkers: Fix for targets with a small-data area

Re: [PATCH 2/2] linkers: Fix for targets with a small-data area

Re: Problem with system time in lpc176x bsp

Rtems-testing bsp add

Re: Fwd: Windows 10 Build

Re: [PATCH 2/2] linkers: Fix for targets with a small-data area

RSB rtems-4.12 gcc-6 dependent package version numbers.

psim ticker size difference with per-element sections

Re: RSB rtems-4.12 gcc-6 dependent package version numbers.

21 matches

Site Navigation

Mail list logo

Footer information