Re: Build Failures on Master (mostly C++ issues)

[Daniel Gutson]

El 9/4/2016 12:24, "Joel Sherrill" <j...@rtems.org> escribió:
>
>
>
> On Sat, Apr 9, 2016 at 10:17 AM, Daniel Gutson <
daniel.gut...@tallertechnologies.com> wrote:
>>
>>
>> El 9/4/2016 12:15, "Joel Sherrill" <j...@rtems.org> escribió:
>> >
>> > Hi
>> >
>> > These are the BSPs which do not build all tests with C++ and the
in-tree network stack enabled:
>> >
>> > + epiphany_sim - GCC ICE building mongoose.c. No investigation.
>>
>> Gcc 6? Could you please attach more data, such as the gcc output and the
test?
>
> Most targets are like this:
>
> arm-rtems4.12-gcc (GCC) 6.0.0 20160327 (RTEMS 4.12, RSB
648e2d5d6c308227c456434238da5f3f881bddc7, Newlib 2.4.0)
>
> But epiphany hasn't been merged yet and has its own issues:
>
> epiphany-rtems4.12-gcc (GCC) 4.9.0 20140411 (RTEMS 4.12, RSB
648e2d5d6c308227c456434238da5f3f881bddc7, Newlib
8b1ede3ce11d53292036aadfcfb6043df0235f9c)
>
> I can post the ICE but not even sure what good it would do.

We can fix it :)

>
>>
>> >
>> > + m32c - does not even build a C++ compiler. This is a small CPU and
there isn't any general support for C++. This was why it was on my list of
automatically disabled.
>>
> This is gcc 6. And I think we just disable C++ for m32c.
>
>>
>> > + moxiesim - cxx_iostream.exe fails to link bcause it can't find
__dso_handle. I don't know if C++ works for moxie-elf or if this is RTEMS
specific.
>
> This is gcc 6. It has had this issue for months. I don't think C++ has
ever worked.
> I have investigated but don't have a clue which tiny bit is wrong.
>
>>
>> > + or1k - needs newlib bumped to match tree.
>
> or1k was also using older gcc 4.9.3. It hasn't been merged yet. I am
updating it
> now to the latest newlib.
>
>>
>> > + sh/gensh4 - undefined reference to __gnu_cxx::__atomic_add(int
volatile*, int) in cxx_iostream test
>>
> This is gcc 6. It has had this issue for months. It broke when the atomic
changes
> and our C++ configuration changed. I have investigated but don't have a
clue
> which tiny bit is wrong.
>
>
>>
>> > --joel
>> >
>> > ___
>> > 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: [PATCH v3] score: Fix simple timecounter support

[Daniel Gutson]

El 21/1/2016 10:08, "Sebastian Huber" 
escribió:
>
> On 21/01/16 14:04, Marcos Díaz wrote:
>>
>> Just a question, isn't this hardware counter used for debugging? This
won't cause us any problem for debugging?
>
>
> Why should it cause problems?

Beside any problem, how this affects debugging since this is using indeed a
dubigging resource?

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

Re: Problem with system time in lpc176x bsp

[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

Question about newlib networking

[Daniel Gutson]

Hi folks,

   I'm confused about the latest patches: does newlib contain a (full)
network stack which we don't use?

Thanks,

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

Re: libfs: are we actually using User/Group IDs?

[Daniel Gutson]

On Sun, Dec 6, 2015 at 10:42 PM, Chris Johns  wrote:
> On 12/05/15 06:49, Martin Galvan wrote:
>>
>> Certainly! This filesystem has been so far implemented in Linux, so
>> I'd assume it's GPLv2.
>
>
> Would it be worth contacting the developer/maintainer and ask about a dual
> license or something we can use?

We are in contact with him (jaegeuk@gmail.com), we can ask
however, Martin, how much Linux code you plan to actually re-use?
Anyway, I will ask about this in a separate mail.

>
>> If this isn't compatible with the RTEMS
>> license, perhaps we could distribute it separately through the Source
>> Builder.
>
>
> The configurations in the master repo for the RSB need to follow the same
> rules as RTEMS in regards to licenses. It becomes too difficult to place the
> responsibility on to our users.
>
> The RSB should support out of tree configurations if set up correctly. This
> means you could maintain and release a configuration file the RSB can use to
> build a GPL package.
>
>
> Chris
> ___
> 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

Re: GPLv2

[Daniel Gutson]

On Sun, Dec 6, 2015 at 11:36 PM, Joel Sherrill <joel.sherr...@gmail.com> wrote:
>
> On Dec 6, 2015 8:06 PM, "Daniel Gutson"
> <daniel.gut...@tallertechnologies.com> wrote:
>>
>> In the f2fs/jffs2 thread a point about licensing arose.
>> Martin mentioned that the original code is part of Linux, assuming
>> that it is GPLv2 (we'll check).
>> However, Chris asked for a dual licensing scheme in order to include
>> it in RTEMS.
>> I read in https://www.rtems.org/license/LICENSE "...GNU General Public
>> License as published by the Free Software Foundation; either version
>> 2..." so I'm confused: why should we ask for a dual license? Isn't
>> GPLv2 indeed the same RTEMS uses?
>>
>
> The RTEMS version includes an exception paragraph that neuters the viral
> nature. See the second paragraph.
>
> https://www.rtems.org/license/LICENSE

So adding a pure GPLv2 file would turn the entire code base free
software... I understand.
Then, what licenses are compatible? I imagine Boost for example, or MIT, right?

>
>> Please explain me.
>>
>> Thanks!
>>
>>Daniel.
>>
>> --
>>
>> 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



-- 

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

Re: [PATCH] Require __getreent()

[Daniel Gutson]

Hi Sebastian,

  sorry for top-posting. How does the lack of this function affect
current RTEMS behavior? What's the impact of not having this? We lived
without this till now, how mandatory is this update?

Thanks!

   Daniel.

On Wed, Nov 25, 2015 at 4:35 AM, Sebastian Huber
 wrote:
> This function is used by Newlib since 2013-07-09 (Git commit
> 9b51cd8c6b9cdd067d9648a7ab952884019c56a5).
> ---
>  cpukit/configure.ac   |  4 
>  cpukit/libcsupport/src/newlibc_reent.c|  9 
>  cpukit/sapi/include/confdefs.h|  2 +-
>  cpukit/score/include/rtems/score/threadimpl.h | 32 
> ---
>  cpukit/score/src/threaddispatch.c | 10 -
>  5 files changed, 5 insertions(+), 52 deletions(-)
>
> diff --git a/cpukit/configure.ac b/cpukit/configure.ac
> index cdf9915..f1589a8 100644
> --- a/cpukit/configure.ac
> +++ b/cpukit/configure.ac
> @@ -180,6 +180,10 @@ AC_CHECK_HEADER([signal.h],[
>AC_CHECK_TYPES([sighandler_t])
>  ])
>
> +if test x"$RTEMS_USE_NEWLIB" = xyes ; then
> +  AC_CHECK_DECLS([__getreent],[],[AC_MSG_ERROR([__getreent() in 
>  is mandatory])],[#include ])
> +fi
> +
>  RTEMS_CHECK_MULTIPROCESSING
>  RTEMS_CHECK_POSIX_API
>  RTEMS_CHECK_NETWORKING
> diff --git a/cpukit/libcsupport/src/newlibc_reent.c 
> b/cpukit/libcsupport/src/newlibc_reent.c
> index bf8847c..26da252 100644
> --- a/cpukit/libcsupport/src/newlibc_reent.c
> +++ b/cpukit/libcsupport/src/newlibc_reent.c
> @@ -35,15 +35,6 @@ bool newlib_create_hook(
>rtems_tcb *creating_task
>  )
>  {
> -#if !defined(__DYNAMIC_REENT__)
> -  if (_Thread_libc_reent == 0)
> -  {
> -_REENT = _GLOBAL_REENT;
> -
> -_Thread_Set_libc_reent (&_REENT);
> -  }
> -#endif
> -
>_REENT_INIT_PTR((creating_task->libc_reent)); /* GCC extension: structure 
> constants */
>
>return true;
> diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
> index 0e83bf1..9ef0bc6 100644
> --- a/cpukit/sapi/include/confdefs.h
> +++ b/cpukit/sapi/include/confdefs.h
> @@ -2417,7 +2417,7 @@ const rtems_libio_helper rtems_fs_init_helper =
>#define CONFIGURE_NUMBER_OF_INITIAL_EXTENSIONS 0
>  #endif
>
> -#if defined(RTEMS_NEWLIB) && defined(__DYNAMIC_REENT__)
> +#if defined(RTEMS_NEWLIB)
>struct _reent *__getreent(void)
>{
>  #ifdef CONFIGURE_DISABLE_NEWLIB_REENTRANCY
> diff --git a/cpukit/score/include/rtems/score/threadimpl.h 
> b/cpukit/score/include/rtems/score/threadimpl.h
> index 906bdb1..cf32082 100644
> --- a/cpukit/score/include/rtems/score/threadimpl.h
> +++ b/cpukit/score/include/rtems/score/threadimpl.h
> @@ -75,16 +75,6 @@ SCORE_EXTERN Thread_Information 
> _Thread_Internal_information;
>  SCORE_EXTERN Thread_Control *_Thread_Allocated_fp;
>  #endif
>
> -#if !defined(__DYNAMIC_REENT__)
> -/**
> - * The C library re-enter-rant global pointer. Some C library implementations
> - * such as newlib have a single global pointer that changed during a context
> - * switch. The pointer points to that global pointer. The Thread control 
> block
> - * holds a pointer to the task specific data.
> - */
> -SCORE_EXTERN struct _reent **_Thread_libc_reent;
> -#endif
> -
>  #define THREAD_CHAIN_NODE_TO_THREAD( node ) \
>RTEMS_CONTAINER_OF( node, Thread_Control, Wait.Node.Chain )
>
> @@ -1501,28 +1491,6 @@ RTEMS_INLINE_ROUTINE void 
> _Thread_Debug_set_real_processor(
>  #endif
>  }
>
> -#if !defined(__DYNAMIC_REENT__)
> -/**
> - * This routine returns the C library re-enterant pointer.
> - */
> -
> -RTEMS_INLINE_ROUTINE struct _reent **_Thread_Get_libc_reent( void )
> -{
> -  return _Thread_libc_reent;
> -}
> -
> -/**
> - * This routine set the C library re-enterant pointer.
> - */
> -
> -RTEMS_INLINE_ROUTINE void _Thread_Set_libc_reent (
> -  struct _reent **libc_reent
> -)
> -{
> -  _Thread_libc_reent = libc_reent;
> -}
> -#endif
> -
>  /** @}*/
>
>  #ifdef __cplusplus
> diff --git a/cpukit/score/src/threaddispatch.c 
> b/cpukit/score/src/threaddispatch.c
> index cce3aff..3ae8335 100644
> --- a/cpukit/score/src/threaddispatch.c
> +++ b/cpukit/score/src/threaddispatch.c
> @@ -104,16 +104,6 @@ void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, 
> ISR_Level level )
>_self->time_of_last_context_switch
>  );
>
> -#if !defined(__DYNAMIC_REENT__)
> -/*
> - * Switch libc's task specific data.
> - */
> -if ( _Thread_libc_reent ) {
> -  executing->libc_reent = *_Thread_libc_reent;
> -  *_Thread_libc_reent = heir->libc_reent;
> -}
> -#endif
> -
>  _User_extensions_Thread_switch( executing, heir );
>  _Thread_Save_fp( executing );
>  _Context_Switch( >Registers, >Registers );
> --
> 1.8.4.5
>
> ___
> 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 

Re: embedded brains @ embedded world, was: Re: Embedded World?

[Daniel Gutson]

El 17/11/2015 6:58, "Thomas Dörfler" <thomas.doerf...@embedded-brains.de>
escribió:
>
> Hello Daniel,

Hello Thomas,

>
> I am not quite sure whether you mean the "embedded world" trade fair in
Nuermberg, 23.-25.February 2016.

Yes.

>
> Our company will be there. We are located at stand 538, hall4.
>
> And we will be happy to see as many RTEMS users as possible face-to-face
during these three days.

Great.

>
> We were even discussing internally whether we should book a conference
room on wednesday for an informal RTEMS users meeting, but my guess is that
we will not reach the critical mass of people interested for this.

Please note that I will attend the Expo, not the Conference.

>
> Looking forward to seeing you all,
>
> Thomas.
>
>
>
> Am 16.11.2015 um 21:23 schrieb Daniel Gutson:
>>
>> Sorry the off-topic email.
>>
>> Who is planning to attend the expo at EW, so we could meet?
>>
>> Thanks,
>>
>> Daniel.
>>
>
> --
> 
> embedded brains GmbH
> Thomas Doerfler
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: thomas.doerf...@embedded-brains.de
> Phone: +49-89-18 94 741-12
> Fax:   +49-89-18 94 741-09
> 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

Re: embedded brains @ embedded world, was: Re: Embedded World?

[Daniel Gutson]

El 17/11/2015 8:51, "Thomas Dörfler" <thomas.doerf...@embedded-brains.de>
escribió:
>
> Hello Daniel,
>
> Expo and conference are in the same building complex. And we will be part
of the expo.

Ah ok, thanks. See you there.

Daniel.

>
> wkr,
>
> Thomas.
>
>
>
> Am 17.11.2015 um 12:47 schrieb Daniel Gutson:
>>
>>
>> El 17/11/2015 6:58, "Thomas Dörfler" <thomas.doerf...@embedded-brains.de>
escribió:
>> >
>> > Hello Daniel,
>>
>> Hello Thomas,
>>
>> >
>> > I am not quite sure whether you mean the "embedded world" trade fair
in Nuermberg, 23.-25.February 2016.
>>
>> Yes.
>>
>> >
>> > Our company will be there. We are located at stand 538, hall4.
>> >
>> > And we will be happy to see as many RTEMS users as possible
face-to-face during these three days.
>>
>> Great.
>>
>> >
>> > We were even discussing internally whether we should book a conference
room on wednesday for an informal RTEMS users meeting, but my guess is that
we will not reach the critical mass of people interested for this.
>>
>> Please note that I will attend the Expo, not the Conference.
>>
>> >
>> > Looking forward to seeing you all,
>> >
>> > Thomas.
>> >
>> >
>> >
>> > Am 16.11.2015 um 21:23 schrieb Daniel Gutson:
>> >>
>> >> Sorry the off-topic email.
>> >>
>> >> Who is planning to attend the expo at EW, so we could meet?
>> >>
>> >> Thanks,
>> >>
>> >> Daniel.
>> >>
>> >
>> > --
>> > 
>> > embedded brains GmbH
>> > Thomas Doerfler
>> > Dornierstr. 4
>> > D-82178 Puchheim
>> > Germany
>> > email: thomas.doerf...@embedded-brains.de
>> > Phone: +49-89-18 94 741-12
>> > Fax:   +49-89-18 94 741-09
>> > 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
>
>
> --
> 
> embedded brains GmbH
> Thomas Doerfler
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: thomas.doerf...@embedded-brains.de
> Phone: +49-89-18 94 741-12
> Fax:   +49-89-18 94 741-09
> 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] Beagle BSP Improvements (GPIO driver)

[Daniel Gutson]

Hi Ketul,

   we are experiencing a deadlock that seems to be caused by

+#define OBTAIN_LOCK(s) assert( rtems_semaphore_obtain(s,\
+  RTEMS_WAIT,   \
+  RTEMS_NO_TIMEOUT  \
+  ) == RTEMS_SUCCESSFUL )
+

which differs from the previous version. Are you sure this is the
intended behavior for in-interrupt context? What if the semaphore is
already locked?
IIUC this causes either a forever sleep or an assertion in case the
semaphore cannot be acquired.

Thanks,

Daniel.

On Tue, Jun 23, 2015 at 11:53 AM, Ketul Shah  wrote:
> Sorry wrong attachment. Kindly review the recent one.
>
> Thanks.
>
> Best Regards,
> Ketul
>
> On 23 June 2015 at 20:20, Ketul Shah  wrote:
>>
>> Hello all,
>>
>> Sorry as I am updating you related to my GPIO API after a huge delay.
>>
>> I have developed it and tested it on my BBB. I did some big changes in the
>> API taking in the account comment(s)/suggestion(s) from my respective
>> mentors.
>>
>> I am also looking the API developed by Andre working for Raspberry Pi. Now
>> I think it is a good time to merge the gpio code as API is getting more
>> stable and generalized.
>>
>> So now it is good time to take the best things from API and we can have
>> common API for GPIO driver running on every embedded board.
>>
>> Your comment(s) are welcomed.
>>
>> Thanks.
>>
>> Best Regards,
>> Ketul
>>
>> On 29 April 2015 at 06:39, Chris Johns  wrote:
>>>
>>>  [ Just catching up ]
>>>
>>> On 26/04/2015 9:26 pm, Ben Gras wrote:
>>> > All,
>>> >
>>> > I think the API as it is (for digital GPIO's) is pretty close to
>>> > generic. I like my suggestion (gpio_* in my previous mail) better as
>>> > more generic. (More configuration is hidden from the application.)
>>> >
>>> > Joel I just read your presentation.
>>> >
>>> > I have come up with a minimal GPIO API based on the above (so
>>> > ultimately based on the RPI API) that just covers the GPIO digital out
>>> > case but allows expansion (with more defines and functions).
>>> >
>>> > https://devel.rtems.org/wiki/TBR/User/BenGras
>>> >
>>> > Is this an idea? Then we can merge this code implementing a reasonably
>>> > generic API without having to flesh out the whole thing.
>>> >
>>>
>>> How do we define hardware specific details without bloating the API ?
>>>
>>> For example on a zynq project I am working on I needed a GPIO interface
>>> and I decided to use a struct to define the pin and the API takes
>>> references to it. For example to control the write enable pin on a flash
>>> device I have:
>>>
>>> static const gpio_pin_def gpio_Flash_WD =
>>> {
>>>   pin:  4,
>>>   output:   true,
>>>   on:   GPIO_FLASH_WD_EN,
>>>   outen:true,
>>>   volts:gpio_LVCMOS33,
>>>   pullup:   true,
>>>   fast: false,
>>>   tristate: false
>>> };
>>>
>>> and then I have:
>>>
>>>gpio_error ge = gpio_setup_pin(_Flash_WD);
>>>if (ge != GPIO_NO_ERROR)
>>>return FLASH_WRITE_LOCK_FAIL;
>>>
>>>
>>>
>>> gpio_output(gpio_Flash_WD.pin, GPIO_FLASH_WD_EN);
>>>
>>>
>>>
>>> I need to set the voltage on the pin on the Zynq but this is Zynq
>>> specific.
>>>
>>> We need a way to let a user convey specific hardware details to the BSP
>>> driver through the API plus we need a light weight API with minimal
>>> internal translations. This approach also lets me define an array of
>>> pins and a single set up call configures them.
>>>
>>> So you could have:
>>>
>>> typedef struct
>>> {
>>> int   pin;   /* The pin number. */
>>> bool  output;/* True for output, false for input. */
>>> bool  on;/* True default output is on */
>>> bool  outen; /* True for output enable on, false for off. */
>>> bool  pullup;/* True to enable the pull up. */
>>> bool  tristate;  /* True to enable tri-state. */
>>> void* platform;  /* Opaque hardware specific set up details. */
>>> } gpio_pin_def;
>>>
>>> where the 'platform' references a struct agreed between the BSP (or
>>> device layer) and the user code. For the generic cases this is not
>>> needed and NULL. It also allows layering where a device set up phase of
>>> user code sets the voltages and the generic code can play with the pin
>>> at a generic level, eg direction etc.
>>>
>>> What locking is being considered in this API ?
>>>
>>> Chris
>>
>>
>
>
> ___
> 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

Re: Tools for RTEMS 4.12

[Daniel Gutson]

On Thu, Nov 5, 2015 at 11:52 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
>
>
> On 05/11/15 15:50, Daniel Gutson wrote:
>>
>> On Thu, Nov 5, 2015 at 11:41 AM, Sebastian Huber
>> <sebastian.hu...@embedded-brains.de>  wrote:
>>>
>>> >Hello,
>>> >
>>> >I would like to add the tools for RTEMS 4.12 to the RSB. The question is
>>> >which GCC version should we use? Since our release process is so slow I
>>> > tend
>>> >to use GCC 6 since it includes support for OpenMP and C++11 threads out
>>> > of
>>> >the box. I use it currently for development and it works quite good at
>>> > least
>>> >on ARM and PowerPC.
>>
>> Out of curiosity: OpenMP on ARM? Could you detail the core name?
>
>
> What do you mean with core name? The Altera Cyclone V and Xilinx Zynq use
> Cortex-A9 MPCore if this is what you mean.

Yes, thanks.

>
>>
>> Thanks,
>>
>> Daniel.
>>
>> ps: we're successfully using gcc 5.2 with custom patches that make
>> RTEMS compile. We are currently working with the gcc community to
>> finish one of them. We can provide them here meanwhile.
>>
>
> What is the problem with 5.2? I didn't experience problems with this GCC
> branch.

We use C++14. The problems I can remember where the recursive call to
calloc and the global register.
Guys? Marcos, Andrés? Please comment.

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



-- 

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

Re: Tools for RTEMS 4.12

[Daniel Gutson]

On Thu, Nov 5, 2015 at 11:41 AM, Sebastian Huber
 wrote:
> Hello,
>
> I would like to add the tools for RTEMS 4.12 to the RSB. The question is
> which GCC version should we use? Since our release process is so slow I tend
> to use GCC 6 since it includes support for OpenMP and C++11 threads out of
> the box. I use it currently for development and it works quite good at least
> on ARM and PowerPC.

Out of curiosity: OpenMP on ARM? Could you detail the core name?

Thanks,

   Daniel.

ps: we're successfully using gcc 5.2 with custom patches that make
RTEMS compile. We are currently working with the gcc community to
finish one of them. We can provide them here meanwhile.

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



-- 

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

Re: 4.11 Branch BSP C++ Build Issues

[Daniel Gutson]

On Wed, Oct 21, 2015 at 6:02 PM, Joel Sherrill
<joel.sherr...@oarcorp.com> wrote:
>
>
> On 10/21/2015 3:52 PM, Daniel Gutson wrote:
>>
>> On Wed, Oct 21, 2015 at 3:41 PM, Joel Sherrill
>> <joel.sherr...@oarcorp.com> wrote:
>>>
>>> Hi
>>>
>>> lm32, moxie, and nios2 all have generic issues with C++ applications
>>> which indicate C++ is not really supported by gcc for these targets.
>>
>>
>> Could you please provide more information/details about the error and
>> messages?
>> What does "C++ is not really supported" mean? C++ is front-end plus
>> the STL, and since
>> the front-end is target agnostic, I'm assuming there is some issue with
>> the STL.
>
>
> Ok.. if you see how to fix these, I am happy to push more testing. :)
>
> ==
> lm32 all bsps fail similar to this
> ==
> lm32-rtems4.11-g++ -B../../../../../lm32_evr_gdbsim/lib/ -specs bsp_specs
> -qrtems -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration
> -Wstrict-prototypes -Wnested-externs   -o cxx_iostream.exe init.o
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev' referenced in section
> `.rodata.cst4' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(eh_terminate.o):
> defined in discarded section
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev[_ZN9__gnu_cxx7__mutexD5Ev]' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(eh_terminate.o)
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev' referenced in section
> `.rodata.cst4' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(new_handler.o):
> defined in discarded section
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev[_ZN9__gnu_cxx7__mutexD5Ev]' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(new_handler.o)
> collect2: error: ld returned 1 exit status
>
> Both linkcmds appear to have the right magic:
>
>   .gcc_except_table   : {
> *(.gcc_except_table)
> *(.gcc_except_table.*)
>   } > sdram
>   ==
> Moxie
> ==
>
> moxie-rtems4.11-g++ -B../../../../../moxiesim/lib/ -specs bsp_specs -qrtems
> -Os -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
> -Wl,--gc-sections -o cxx_iostream.exe init.o
> init.o: In function `__static_initialization_and_destruction_0':
> /data/home/joel/rtems-4.11-work/tools/lib/gcc/moxie-rtems4.11/4.9.3/include/c++/iostream:74:
> undefined reference to `__dso_handle'
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(locale_init.o):
> In function `get_locale_mutex':
> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/moxie-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/moxie-rtems4.11/libstdc++-v3/src/c++98/../../../../../gcc-4.9.3/libstdc++-v3/src/c++98/locale_init.cc:36:
> undefined reference to `__dso_handle'
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(eh_alloc.o):
> In function `__static_initialization_and_destruction_0':
> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/moxie-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/moxie-rtems4.11/libstdc++-v3/libsupc++/../../../../gcc-4.9.3/libstdc++-v3/libsupc++/eh_alloc.cc:96:
> undefined reference to `__dso_handle'
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(eh_globals.o):
> In function `__static_initialization_and_destruction_0':
>

Those two (lm32 and Moxie) have problems with exception handling and
the linker scripts.
NIOS2 seems that it wants to use atomics but are not implemented,
instead of using the pthreads layer. (Sebastian?)

We can fix all of them but unfortunately have no time :(
What about at least disabling EH? I suggest build a multilib without
exceptions handling support (-fno-exceptions which will apply to the
STL).


> ==
> NIOS2
> ==
>
> Missing needed atomic operations.
>
> nios2-rtems4.11-g++ -B../../../../../nios2_iss/lib/ -specs bsp_specs -qrtems
> -mno-hw-mul -mno-hw-div -O0 -g -Wall -Wmissing-prototypes
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
> -mno-hw-mul -mno-hw-div   -o cxx_iostream.exe init.o
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/nios2-rtems4.11/4.9.3/

Re: [PATCH] Fix exception handler for supporting FPU

[Daniel Gutson]

On Wed, Oct 7, 2015 at 8:22 PM, Chris Johns <chr...@rtems.org> wrote:
> On 7/10/2015 11:00 pm, Daniel Gutson wrote:
>>
>> FWIW no need from feedback from us.
>>
>
> Can we assume this is an ok from you?

Yes.

>
> Chris



-- 

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

Re: [PATCH] Fix exception handler for supporting FPU

[Daniel Gutson]

On Wed, Oct 7, 2015 at 4:05 AM, Sebastian Huber
 wrote:
>
>
> On 07/10/15 09:04, Chris Johns wrote:
>>
>> On 7/10/2015 4:33 pm, Sebastian Huber wrote:
>>>
>>> >
>>> >
>>> >On 07/10/15 05:13, Chris Johns wrote:

 >>On 23/09/2015 11:33 am, Gedare Bloom wrote:
>>
>> >>> >ping. i will try to get to this tomorrow if no one else does.

 >>What happened to this change?
>>>
>>> >
>>> >https://lists.rtems.org/pipermail/devel/2015-September/012612.html
>>> >
>>
>> Ah yes I remember now and why I could not find them on 4.11 branch. Are
>> they ok for 4.11?
>
>
> I don't know. I wait for feedback.

FWIW no need from feedback from us.

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



-- 

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

Re: Math lib inclusion in BSP

[Daniel Gutson]

On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan
 wrote:
> Hey all,
>
> We are developing a new BSP that uses math.h in few of the BSP files. I do

May I ask why do you need floating point operations in a kernel? At
least, what sort of operations and why not move them upwards.

> understand that the math library functions are not part of standard C
> library and has to be linked using "-lm". So I include "LD_LIBS  += -lm" in
> the custom .cgf config file but this doesn't seem to work. I think this has
> to be linked in a proper order. Could someone help with this?
>
> Heres the custom config file:
>
> include $(RTEMS_ROOT)/make/custom/default.cfg
>
> RTEMS_CPU = arm
>
> LD_LIBS += -lm
>
> CPU_CFLAGS = -march=armv7-m -mthumb
>
> CFLAGS_OPTIMIZE_V = -O0 -g -mfloat-abi=hard -mfpu=fpv4-sp-d16
>
> Thanks and Regards,
> Sudarshan
> ___
> 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

Re: Math lib inclusion in BSP

[Daniel Gutson]

El 25/9/2015 13:17, "sudarshan.rajagopalan" <sudarshan.rajagopa...@vecna.com>
escribió:
>
> On 2015-09-25 11:06, Daniel Gutson wrote:
>>
>> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan
>> <sudarshan.rajagopa...@vecna.com> wrote:
>>>
>>> Hey all,
>>>
>>> We are developing a new BSP that uses math.h in few of the BSP files. I
do
>>
>>
>> May I ask why do you need floating point operations in a kernel? At
>> least, what sort of operations and why not move them upwards.
>
>
> We are doing floating point operations in one of the device drivers as
part of the BSP - to perform buadrate calculation, to be specific, which
involes inverse operations and using roundf().

How will you handle fp exceptions?
Did you consider using fixed point?
>
>
>>
>>> understand that the math library functions are not part of standard C
>>> library and has to be linked using "-lm". So I include "LD_LIBS  +=
-lm" in
>>> the custom .cgf config file but this doesn't seem to work. I think this
has
>>> to be linked in a proper order. Could someone help with this?
>>>
>>> Heres the custom config file:
>>>
>>> include $(RTEMS_ROOT)/make/custom/default.cfg
>>>
>>> RTEMS_CPU = arm
>>>
>>> LD_LIBS += -lm
>>>
>>> CPU_CFLAGS = -march=armv7-m -mthumb
>>>
>>> CFLAGS_OPTIMIZE_V = -O0 -g -mfloat-abi=hard -mfpu=fpv4-sp-d16
>>>
>>> Thanks and Regards,
>>> Sudarshan
>>> ___
>>> 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: broken gcc 5.2

[Daniel Gutson]

On Fri, Sep 18, 2015 at 5:10 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
> Hello Daniel,
>
> there was a discussion about this on this mailing list. I think the result
> was that GCC is working as intended:
>
> https://lists.rtems.org/pipermail/devel/2015-July/011879.html

Yes. Semantic is changed but after the discussion we concluded that it
is fine; there is however a corner case where the optimization worsens
performance, but I concede it's uncommon.
Nevertheless the motivation was the recursive calloc() issue; someone
recommended -fno-builtin-malloc but I will continue the discussion to
see what's the best solution is. We are considering these
alternatives:

   1) -fno-builtin-malloc: currently works, but I don't like it,
because I don't want to disable the gcc's builtin malloc everywhere
just because this very case
   2) -fno-builtin-calloc: currently doesn't work (and it should);
despite I think that the fact that it should work whereas it doesn't
is a bug, I don't have a strong position about this, so I want to
continue the discussion.
   3) flag the function with an optimization() attribute. The
attribute is reportedly broken, so this (calloc) fix involves fixing
the optimization-related attribute machinery which grows the scope far
beyond the original issue. Additionally, I don't like to disable _all_
the optimizations in calloc() just because this one.
   4) add a flag to enable/disable the calloc=malloc+memset
optimization. Easy to implement, but impacts in all the code just
because this function.
   5) disable the optimization if the caller function is calloc()
itself. This is also somewhat easy to implement, but maybe fragile if
calloc calls another function that does the malloc+memset.

I'm sympathetic towards 2 and 5. I will get consensus with other gcc
maintainers and see what comes out and will let you know.

   Daniel.

>
> On 17/09/15 21:39, Daniel Gutson wrote:
>>
>> Hi,
>>
>>we are working towards compiling RTEMS for gcc 5.2 (since we are
>> working in a fork of the latter).
>>
>> We found a bug that Sebastian previously found, which I reported here:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
>> Not only it causes calloc() to call itself (recursively), but the
>> (arguably) optimization severely breaks the semantic as shown in the
>> bug report.
>>
>> Andres will fix it and will let you know about the progress.
>>
>> Thanks,
>>
>> Daniel.
>>
>
> --
> 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.
>



-- 

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

broken gcc 5.2

[Daniel Gutson]

Hi,

  we are working towards compiling RTEMS for gcc 5.2 (since we are
working in a fork of the latter).

We found a bug that Sebastian previously found, which I reported here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Not only it causes calloc() to call itself (recursively), but the
(arguably) optimization severely breaks the semantic as shown in the
bug report.

Andres will fix it and will let you know about the progress.

Thanks,

   Daniel.

-- 

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

Re: Nice surprise with C++11

[Daniel Gutson]

Update:
  fix sent https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01184.html

Waiting for review.

   Daniel.

On Thu, Aug 13, 2015 at 7:02 PM, Daniel Gutson
<daniel.gut...@tallertechnologies.com> wrote:
> I have been desperately busy to fix this, though we are indeed
> interested in the fix since we'll use C++14 soon.
> That's why I will address this a bit later. Sorry the delay.
>
>Daniel.
>
> On Wed, Aug 5, 2015 at 7:36 PM, Daniel Gutson
> <daniel.gut...@tallertechnologies.com> wrote:
>> On Fri, Jul 31, 2015 at 9:56 AM, Sebastian Huber
>> <sebastian.hu...@embedded-brains.de> wrote:
>>>
>>>
>>> On 31/07/15 14:51, Daniel Gutson wrote:
>>>>
>>>>
>>>> > Is it possible to construct objects without an address via plain C++?
>>>>
>>>> Sorry I don't understand the question. Rephrase please?
>>>>
>>>> Global objects and objects of static storage duration don't take an
>>>> address.
>>>>
>>>
>>> This register asm variable has no address, since this is a real register.
>>> This, however, is not a problem:
>>>
>>> int *h(void)
>>> {
>>> register int i;
>>> return 
>>>
>>> }
>>
>> The 'register' keyword is deprecated since C++11.
>> Additionally, C++ requires that all objects have unique addresses, that's why
>> struct X{};
>> sizeof(X) > 0
>>
>> (and that's why the "empty ase class optimization" idiom exists).
>>
>> Moreover, taking the address of an object prevents such object to
>> dwell in a register.
>>
>> In your example, even in previous C++ versions, should prevent the
>> 'register' hint to be honored,
>> thus returning a temporal address to the stack (which would be invalid
>> in the caller's context).
>>
>> So the short answer is NO.
>>
>> Did I answer your question? Is there any case this should be possible?
>> (consider that I'm pursuing
>> new C++ features for embedded systems in the C++ committee).
>>
>>Daniel.
>>
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>>
>> 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
>
>
>
> --
>
> 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



-- 

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

Re: Memory protection on RTEMS?

[Daniel Gutson]

El 9/9/2015 16:14, "Gedare Bloom"  escribió:
>
> On Wed, Sep 9, 2015 at 2:54 PM, Sebastian Huber
>  wrote:
> > Hello Martin,
> >
> > - Martin Galvan  schrieb:
> >> Hi there! We were looking at the RTEMS SMP support, and wondered what
> >> would it take for the system to support some form of memory protection
> >> (say, an MPU). Is it possible, and if so, how hard would it be?
> >
> > the question is, what is "some form of memory protection" for you?
> >
> +1. Requirements differ in this space. Note that we do not intend to
> have supervisor-privilege, so memory protection may be more applicable
> for safety features or debugging, rather than security. Security is
> guaranteed only if you can ensure no code injection and you have a
> trusted code base.
>
> > A process model for RTEMS makes no sense. For this you better use a
micro kernel or Linux.

We want to protect a real time task's memory from being written or
generally accessed from another task. That smells like processes, but the
truth is we just need memory iisolation/protection meaning that a task
trying to access something marked as owned by another task is because there
is a bug and an action shall be taken (e.g. restart the offending task). Is
there already any kind of hardware support for this?

Thanks,

  Daniel.

> >
> > The ARMv7-A and some PowerPC BSPs have write protection for code and
read-only data. On some BSPs, read/write to the NULL pointer leads to an
exception.  This is quite handy during development, but offers no real
benefit for a production system.
> >
> > For one customer we implemented a stack protection, a thread can only
access its own stack, but this is quite non-standard.
> >
> >>
> >> We also saw this:
> >>
> >> https://devel.rtems.org/wiki/Projects/MMU_Support
> >>
> >> What's the status of this project?
> >
> > I don't know. MMU support tends to be highly architecture specific, so
the development of a general purpose API is quite difficult.
> >
> I am (as we speak) working on a proposal to look in this direction.
> I'm happy to talk more or to consider how to align our efforts.
>
> >>
> >> On the other hand, we noticed that LEON3 IP Cores usually implement an
> >> MMU instead of just an MPU. Would it be feasible to support that?
> >
> > The GR740 has an IOMMU (chapter 17).
> >
> > http://microelectronics.esa.int/ngmp/GR740-UM-DS-v1.pdf
> >
> > --
> > 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.huber at 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 v2 4/5] cpukit/libmisc/dumpbuf/dumpbuf.c: Fix undefined behavior for sprintf()

[Daniel Gutson]

On Thu, Sep 3, 2015 at 1:21 PM, Joel Sherrill  wrote:
>
>
> On 9/2/2015 4:54 PM, Martin Galvan wrote:
>>
>> I also used the 'n' versions of the string functions, #define'd magic
>> numbers
>> and added a few comments.
>
>
> Great on the 'n' versions!
>
> One comment. Why is the output buffer now static? I know it
> moves it off the stack but what's the consensus on an 80
> byte array on a stack?

There are some reasons:
  1) out of the stack, here, means that it will be moved as a static
memory. If it doesn't fit, the toolchain will warn.
  2) we don't know how much stack memory is left. This is specially
important in a debugging function which
  could be called in a faulty context.
  3) 80 bytes is not that low.

>
>
>>
>> Updates #2405.
>> ---
>>   cpukit/libmisc/dumpbuf/dumpbuf.c | 121
>> ---
>>   1 file changed, 75 insertions(+), 46 deletions(-)
>>
>> diff --git a/cpukit/libmisc/dumpbuf/dumpbuf.c
>> b/cpukit/libmisc/dumpbuf/dumpbuf.c
>> index 9d34d42..bb63997 100644
>> --- a/cpukit/libmisc/dumpbuf/dumpbuf.c
>> +++ b/cpukit/libmisc/dumpbuf/dumpbuf.c
>> @@ -6,7 +6,7 @@
>>*/
>>
>>   /*
>> - *  COPYRIGHT (c) 1997-2007.
>> + *  COPYRIGHT (c) 1997-2015.
>>*  On-Line Applications Research Corporation (OAR).
>>*
>>*  The license and distribution terms for this file may in
>> @@ -24,62 +24,91 @@
>>   #include 
>>   #include 
>>
>> +#define HEX_FMT_LENGTH 3   /* Length of the formatted hex string. */
>> +#define ASCII_FMT_LENGTH 1 /* Length of the formatted ASCII string. */
>> +#define BYTES_PER_ROW 16/* Amount of bytes from buffer shown in each
>> row. */
>> +#define BARS 2 /* Amount of bars in each row. */
>> +/* Max length of each row string. */
>> +#define ROW_LENGTH (BYTES_PER_ROW * (HEX_FMT_LENGTH + ASCII_FMT_LENGTH) +
>> BARS)
>> +
>>   /*
>>*  Put the body below rtems_print_buffer so it won't get inlined.
>>*/
>>
>> -static inline void Dump_Line(
>> -  const unsigned char *buffer,
>> -  int  length
>> -);
>> +static void Dump_Line(const unsigned char *buffer, const unsigned int
>> length);
>>
>> -void rtems_print_buffer(
>> -  const unsigned char *buffer,
>> -  int  length
>> -)
>> +/**
>> + * @brief Print \p length bytes from \p buffer, both in hex and ASCII.
>> + * Printing will be done in rows, each showing BYTES_PER_ROW bytes.
>> + * @details Non-printable chars will appear as dots.
>> + *
>> + * @param buffer The buffer we'll print.
>> + * @param length Amount of bytes from \p buffer we'll print. This can't
>> be
>> + * unsigned because we don't have a way to check if we're erroneously
>> getting
>> + * a negative \p length.
>> + */
>> +void rtems_print_buffer(const unsigned char *buffer, const int length)
>>   {
>> +  unsigned int i, mod, max;
>>
>> -  int i, mod, max;
>> -
>> -  if ( !length ) return;
>> +  if (length > 0) {
>> +mod = length % BYTES_PER_ROW;
>>
>> -  mod = length % 16;
>> +max = length - mod;
>>
>> -  max = length - mod;
>> +/* Print length / BYTES_PER_ROW rows. */
>> +for (i = 0; i < max; i += BYTES_PER_ROW) {
>> +  Dump_Line([i], BYTES_PER_ROW);
>> +}
>>
>> -  for ( i=0 ; i> -Dump_Line( [ i ], 16 );
>> -
>> -  if ( mod )
>> -Dump_Line( [ max ], mod );
>> +/* Print another row with the remaining bytes. */
>> +if (mod > 0) {
>> +  Dump_Line([max], mod);
>> +}
>> +  } else {
>> +printk("Error: length must be greater than zero.");
>> +  }
>>   }
>>
>> -static inline void Dump_Line(
>> -  const unsigned char *buffer,
>> -  int  length
>> -)
>> +/**
>> + * @brief Print \p length bytes from \p buffer, both in hex and ASCII.
>> + * @details Non-printable chars will appear as dots.
>> + *
>> + * @param buffer The buffer we'll print.
>> + * @param length Amount of bytes from \p buffer we'll print.
>> + */
>> +static void Dump_Line(const unsigned char *buffer, const unsigned int
>> length)
>>   {
>> -
>> -  int  i;
>> -  char line_buffer[120];
>> -
>> -  line_buffer[0] = '\0';
>> -
>> -  for( i=0 ; i> -sprintf( line_buffer, "%s%02x ", line_buffer, buffer[ i ] );
>> -
>> -  for( ; i<16 ; i++ )
>> -strcat( line_buffer, "   " );
>> -
>> -  strcat( line_buffer, "|" );
>> -  for( i=0 ; i> -sprintf( line_buffer, "%s%c", line_buffer,
>> - isprint( buffer[ i ] ) ? buffer[ i ] : '.' );
>> -
>> -  for( ; i<16 ; i++ )
>> -strcat( line_buffer, " " );
>> -
>> -  strcat( line_buffer, "|\n" );
>> -
>> -  printk( line_buffer );
>> +  unsigned int i;
>> +  static unsigned char line_buffer[ROW_LENGTH] = "";
>> +  size_t tmp_len;
>> +
>> +  /* Output the hex value of each byte. */
>> +  for (i = 0; i < length; ++i) {
>> +snprintf(_buffer[i * HEX_FMT_LENGTH], HEX_FMT_LENGTH + 1,
>> + "%02x ", buffer[i]);
>> +  }
>> +
>> +  /* Fill the remaining space with whitespace (if necessary). */
>> +  for (; i < BYTES_PER_ROW; ++i) {
>> +strncat(line_buffer, "   ", 

Re: [PATCH] cpukit/libnetworking/rtems/rtems_dhcp.c: Fix compilation error

[Daniel Gutson]

On Thu, Sep 3, 2015 at 5:44 PM, Joel Sherrill  wrote:
> Should be committed now.
>
> I guess one of us should have compiled it. :)

Don't worry, Martin will buy some beers because of this.
Cheers.

  Daniel.

>
> --joel
>
> On 9/3/2015 3:25 PM, Martin Galvan wrote:
>>
>> Apparently 'free' is defined as a macro which takes two arguments and
>> calls
>> rtems_bsdnet_free. When fixing #2405 I added a missing 'free' but didn't
>> notice
>> it was non-standard.
>>
>> Closes #2410.
>> ---
>>   cpukit/libnetworking/rtems/rtems_dhcp.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/cpukit/libnetworking/rtems/rtems_dhcp.c
>> b/cpukit/libnetworking/rtems/rtems_dhcp.c
>> index 87be238..cb6966d 100644
>> --- a/cpukit/libnetworking/rtems/rtems_dhcp.c
>> +++ b/cpukit/libnetworking/rtems/rtems_dhcp.c
>> @@ -405,7 +405,7 @@ process_options (unsigned char *optbuf, int
>> optbufSize)
>>   strncpy (dhcp_hostname, p, len);
>> } else {  /* realloc failed */
>>   printf ("dhcpc: realloc failed (%s:%d)", __FILE__,
>> __LINE__);
>> -free (dhcp_hostname);
>> +free (dhcp_hostname, 0);
>>   dhcp_hostname = NULL;
>> }
>>   } else { /* dhcp_hostname == NULL */
>>
>
> --
> 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



-- 

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

Re: [PATCH] [RTEMS] Update RTEMS thread model

[Daniel Gutson]

El 2/9/2015 5:28, "Sebastian Huber" <sebastian.hu...@embedded-brains.de>
escribió:
>
>
>
> On 02/09/15 02:50, Chris Johns wrote:
>>
>> On 1/09/2015 8:52 pm, Daniel Gutson wrote:
>>>
>>> >
>>> >El 31/7/2015 3:28, "Chris Johns" <chr...@rtems.org
>>> ><mailto:chr...@rtems.org>> escribió:
>>>>
>>>> >>
>>>> >>On 31/07/2015 4:11 pm, Sebastian Huber wrote:
>>>>>
>>>>> >> >For synchronization objects use the self-contained objects
available via
>>>>> >> >Newlib .
>>>>> >> >
>>>>> >> >
>>>
>>> >
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a
>>>>>
>>>>> >> >
>>>>> >> >Enable the C++11 threads using .  So, the threads are
only
>>>>> >> >supported in case the POSIX API is enabled in RTEMS.  In the long
run
>>>>> >> >support for thread join and detach should be added to the API
>>>>> >> >independent RTEMS services.
>>>>> >> >
>>>>
>>>> >>
>>>> >>Is this for 4.12 ?
>>>> >>
>>>> >>What happens if I build RTEMS with --disable-posix ? If I use locale
in
>>>> >>C++ it pulls in the 'once' support which pulls in this file which
would
>>>> >>give unresolved externals. There is a PR against me for libstdc++ not
>>>> >>checking the return code. Is it time for the --enable-posix option
to go
>>>> >>and to always nave it enabled ?
>>>
>>> >
>>> >Please don't. The POSIX layer takes valuable resurces and it is not
>>> >always needed.
>>> >
>>
>> Maybe we should look into this and fix the reasons. Any code not
>> required should not be included. This is an on going effort in RTEMS and
>> it requires we expose the cases.
>
>
> We have all the infrastructure to fix this. One part is
>
> CFLAGS += -ffunction-sections -fdata-sections
> LDFLAGS += -Wl,--gc-sections
>
> The other part a linker set based initialization (fully implemented in
libbsd). One issue is that we have to add support for this in all linker
command files. So we need just someone who has time to do this.

Could you please create a ticket for this dumping all the useful
informatiom you have in your head there :) since we are interested so we'll
likely do it, and any further question can be discussed in the ticket.

>
>
> --
> 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] [RTEMS] Update RTEMS thread model

[Daniel Gutson]

El 2/9/2015 5:17, "Sebastian Huber" 
escribió:
>
>
>
> On 01/09/15 13:05, Sebastian Huber wrote:
>>
>> On 01/09/15 12:10, Sebastian Huber wrote:
>>>
>>> Shared mutexes are not implemented in general.
>>
>>
>> This works now also:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00027.html
>>
>
> With this additional fix:
>
> https://gcc.gnu.org/ml/gcc/2015-09/msg00021.html
>
> We have these results:
>
>
> Target is arm-unknown-rtems4.11
> Host   is arm-unknown-rtems4.11
> Build  is x86_64-pc-linux-gnu
>
> === libstdc++ tests ===
>
> Schedule of variations:
>
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard
>
> Running target
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard
>
> Using
/scratch/git-rtems-testing/dejagnu/boards/rtems-arm-realview_pbx_a9_qemu.exp
as board description file for target.
> Using /usr/share/dejagnu/config/sim.exp as generic interface file for
target.
> Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description
file for target.
> Using
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/config/default.exp
as tool-and-target-specific interface file.
> Running
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-abi/abi.exp
...
> Running
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
> FAIL: 25_algorithms/copy/streambuf_iterators/wchar_t/4.cc execution test
> FAIL: 25_algorithms/find/istreambuf_iterators/wchar_t/2.cc execution test
> FAIL: 25_algorithms/random_shuffle/moveable.cc execution test

I'm very interested in this last one. Is this an XFail? Could you please
post both the dejagnu test and the output?
We use move semantics everywhere and I'd want to be sure it's working OK.
Specially since this doesn't seem to be related to concurrency but just
algorithms.

Thanks,

Daniel.

> FAIL: 27_io/basic_istream/extractors_other/wchar_t/2.cc execution test
> FAIL: 27_io/basic_istream/get/wchar_t/2.cc execution test
> FAIL: 27_io/basic_istream/ignore/wchar_t/3.cc execution test
> FAIL: 27_io/basic_istream/seekg/wchar_t/sstream.cc execution test
> FAIL: 27_io/basic_istream/tellg/wchar_t/sstream.cc execution test
> FAIL: 27_io/basic_ostream/inserters_other/wchar_t/1.cc execution test
> FAIL: 27_io/basic_stringbuf/setbuf/char/4.cc execution test
> FAIL: 27_io/objects/wchar_t/12048-1.cc execution test
> FAIL: 27_io/objects/wchar_t/12048-2.cc execution test
> FAIL: 27_io/objects/wchar_t/12048-3.cc execution test
> FAIL: 27_io/objects/wchar_t/12048-4.cc execution test
> WARNING: program timed out.
> FAIL: 30_threads/async/42819.cc execution test
> WARNING: program timed out.
> FAIL: 30_threads/async/49668.cc execution test
> WARNING: program timed out.
> FAIL: 30_threads/async/any.cc execution test
> WARNING: program timed out.
> FAIL: 30_threads/async/async.cc execution test
>
> WARNING: program timed out.
> FAIL: 30_threads/condition_variable/members/3.cc execution test
> FAIL: 30_threads/shared_timed_mutex/try_lock/3.cc execution test
> WARNING: program timed out.
> FAIL: 30_threads/thread/native_handle/cancel.cc execution test
> FAIL: 30_threads/timed_mutex/try_lock_until/57641.cc execution test
> FAIL: tr1/8_c_compatibility/complex/50880.cc (test for excess errors)
> WARNING: tr1/8_c_compatibility/complex/50880.cc compilation failed to
produce executable
> FAIL: tr1/8_c_compatibility/complex/functions.cc (test for excess errors)
> Running
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
...
> Running
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp
...
>
> === libstdc++ Summary ===
>
> # of expected passes9029
> # of unexpected failures24
>
> # of expected failures  65
> # of unsupported tests  726
>
> Biggest issue: the thread cancel/exit problems. Since this is not an
issue with the thread model, I will commit the patch tomorrow if nobody
objects.
>
>
> --
> 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

Re: building RTEMS 4.11 leon3 with floating point support?

[Daniel Gutson]

El 2/9/2015 11:14, "Joel Sherrill"  escribió:
>
>
>
> On 8/31/2015 5:47 AM, Cudmore, Alan P. (GSFC-5820) wrote:
>>
>> Having a floating point configuration of the BSP makes sense. I was able
>> to rebuild the BSP with the hardware floating point compiler option and
it
>> works.
>>
>> I did get a floating point exception in the FTP task and had to change
the
>> FTP task create to enable floating point. Is it worth submitting a patch
>> to change that?
>
>
> What did it use the FPU for? Is this a case where GCC emits FPU
instructions
> just to move data or calculate array indices?

Offtopic: this seems very suboptimal. Have you got an actual example of
that? I'd like to take a look.

>
> On some CPUs, when hard FP is turned on, GCC assumes the FPU can be used
> for some non-intuitive things and it is safer to implicitly make all tasks
> FP rather than letting people trip over implicit uses of the FPU.
>
> --joel
>
>
>> Thanks,
>> Alan
>>
>>
>> On 8/31/15, 2:40 AM, "Sebastian Huber"
>>  wrote:
>>
>>> Hello Alan,
>>>
>>> I am not sure how Gaisler manages this in their RCC, but I think for
>>> standard RTEMS we need additional BSPs (e.g. via leon3_fp.cfg and
>>> ngmp_fp.cfg configuration files).
>>>
>>> On 17/08/15 17:29, Cudmore, Alan P. (GSFC-5820) wrote:

 Hi,
 We are currently trying to use the leon3 BSP for RTEMS 4.11.
 We have used the 4.10 RCC/Gaisler tools with the Driver Manager in the
 past, but we would like to be on 4.11 for the SMP support.

 When I build the 4.11 leon3 BSP, I seem to only have soft-float
 support. When I try to build with the ‹enable-multilib configure
 switch, the build fails. Before I start trying to determine the cause
 of the compile failure, I wanted to make sure I am enabling floating
 point support for the LEON3 correctly.

 Thanks,
 Alan




 ___
 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
>>
>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] cpukit/libmisc/dumpbuf/dumpbuf.c: Fix undefined behavior for sprintf().

[Daniel Gutson]

El 1/9/2015 23:10, "Joel Sherrill" <joel.sherr...@oarcorp.com> escribió:
>
>
>
> On September 1, 2015 8:33:54 PM CDT, Daniel Gutson <
daniel.gut...@tallertechnologies.com> wrote:
> >Is there any reason to not declare these variables as unsigned (int)?
> >IIUC strlen returns an unsigned integral. Sign-correctnesd doesn't hurt
> >and I saw many bugs caused by the lack of it (the last one being pushed
> >few says ago in the Chromium beowser).
>
> I was wondering if they should be size_t when I looked at the code. I
will check that and change it.
>
> I was more concerned that none of the calls used the n version of the
string or snprintf() method. I planned to fix that on the master. We
probably need to make a rule to ban use of the non-n versions of the string
methods.

I couldn't agree more.

>
>
>
> >El 1/9/2015 18:41, "Joel Sherrill" <joel.sherr...@oarcorp.com>
> >escribió:
> >
> >Updates #2405.
> >---
> > cpukit/libmisc/dumpbuf/dumpbuf.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> >diff --git a/cpukit/libmisc/dumpbuf/dumpbuf.c
> >b/cpukit/libmisc/dumpbuf/dumpbuf.c
> >index 9d34d42..36a8656 100644
> >--- a/cpukit/libmisc/dumpbuf/dumpbuf.c
> >+++ b/cpukit/libmisc/dumpbuf/dumpbuf.c
> >@@ -62,18 +62,20 @@ static inline void Dump_Line(
> >
> >   int  i;
> >   char line_buffer[120];
> >+  int  len;
> >
> >   line_buffer[0] = '\0';
> >
> >   for( i=0 ; i >-sprintf( line_buffer, "%s%02x ", line_buffer, buffer[ i ] );
> >+sprintf( _buffer[i*3], "%02x ", buffer[ i ] );
> >
> >   for( ; i<16 ; i++ )
> > strcat( line_buffer, "   " );
> >
> >   strcat( line_buffer, "|" );
> >+  len = strlen( line_buffer );
> >   for( i=0 ; i >-sprintf( line_buffer, "%s%c", line_buffer,
> >+sprintf( _buffer[len+i], "%c",
> >  isprint( buffer[ i ] ) ? buffer[ i ] : '.' );
> >
> >   for( ; i<16 ; i++ )
> >--
> >1.8.3.1
> >
> >___
> >devel mailing list
> >devel@rtems.org
> >http://lists.rtems.org/mailman/listinfo/devel
>
> --joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] cpukit/libmisc/dumpbuf/dumpbuf.c: Fix undefined behavior for sprintf().

[Daniel Gutson]

Is there any reason to not declare these variables as unsigned (int)? IIUC
strlen returns an unsigned integral. Sign-correctnesd doesn't hurt and I
saw many bugs caused by the lack of it (the last one being pushed few says
ago in the Chromium beowser).
El 1/9/2015 18:41, "Joel Sherrill"  escribió:

> Updates #2405.
> ---
>  cpukit/libmisc/dumpbuf/dumpbuf.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/libmisc/dumpbuf/dumpbuf.c
> b/cpukit/libmisc/dumpbuf/dumpbuf.c
> index 9d34d42..36a8656 100644
> --- a/cpukit/libmisc/dumpbuf/dumpbuf.c
> +++ b/cpukit/libmisc/dumpbuf/dumpbuf.c
> @@ -62,18 +62,20 @@ static inline void Dump_Line(
>
>int  i;
>char line_buffer[120];
> +  int  len;
>
>line_buffer[0] = '\0';
>
>for( i=0 ; i -sprintf( line_buffer, "%s%02x ", line_buffer, buffer[ i ] );
> +sprintf( _buffer[i*3], "%02x ", buffer[ i ] );
>
>for( ; i<16 ; i++ )
>  strcat( line_buffer, "   " );
>
>strcat( line_buffer, "|" );
> +  len = strlen( line_buffer );
>for( i=0 ; i -sprintf( line_buffer, "%s%c", line_buffer,
> +sprintf( _buffer[len+i], "%c",
>   isprint( buffer[ i ] ) ? buffer[ i ] : '.' );
>
>for( ; i<16 ; i++ )
> --
> 1.8.3.1
>
> ___
> 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: [PATCH] [RTEMS] Update RTEMS thread model

[Daniel Gutson]

El 31/7/2015 3:28, "Chris Johns"  escribió:
>
> On 31/07/2015 4:11 pm, Sebastian Huber wrote:
> > For synchronization objects use the self-contained objects available via
> > Newlib .
> >
> >
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a
> >
> > Enable the C++11 threads using .  So, the threads are only
> > supported in case the POSIX API is enabled in RTEMS.  In the long run
> > support for thread join and detach should be added to the API
> > independent RTEMS services.
> >
>
> Is this for 4.12 ?
>
> What happens if I build RTEMS with --disable-posix ? If I use locale in
> C++ it pulls in the 'once' support which pulls in this file which would
> give unresolved externals. There is a PR against me for libstdc++ not
> checking the return code. Is it time for the --enable-posix option to go
> and to always nave it enabled ?

Please don't. The POSIX layer takes valuable resurces and it is not always
needed.

>
> I feel 'tiny' support should be by not linking rather than configure
magic.
>
> 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: [PATCH v3] ARMv7M: Fix exception handler for supporting FPU

[Daniel Gutson]

Side question to Joel and others: is this enough to credit Sudarshan?
He did an amazing job for finding the bug and proposing an initial
solution.

On Mon, Aug 31, 2015 at 11:37 AM, Martin Galvan
 wrote:
> On exception entry, _ARMV7M_Exception_default stores the previous Stack 
> Pointer
> in a CPU_Exception_frame. The SP can be MSP or PSP, depending on the mode
> in which the exception was taken. To know this, we must check the value of LR.
>
> Right now the code checks whether it should store MSP or PSP by comparing LR 
> to
> -3. However, this doesn't work if we're using an FPU. This patch fixes that
> by checking bit 2 of LR, which indicates which SP we were using.
>
> Thanks to Sudarshan Rajagopalan for finding the bug and proposing a first
> version of the fix.
>
> Closes #2401.
>
> ---
>  cpukit/score/cpu/arm/armv7m-exception-default.c | 27 
> +
>  1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/cpukit/score/cpu/arm/armv7m-exception-default.c 
> b/cpukit/score/cpu/arm/armv7m-exception-default.c
> index e890cdf..d04dbea 100644
> --- a/cpukit/score/cpu/arm/armv7m-exception-default.c
> +++ b/cpukit/score/cpu/arm/armv7m-exception-default.c
> @@ -22,16 +22,27 @@
>
>  void __attribute__((naked)) _ARMV7M_Exception_default( void )
>  {
> +/* On exception entry, ARMv7M saves context state onto a stack pointed to
> + * by either MSP or PSP. The value stored in LR indicates whether we were
> + * in Thread or Handler mode, whether we were using the FPU (if any),
> + * and which stack pointer we were using.
> + * In particular, bit 2 of LR will be 0 if we were using MSP.
> + *
> + * For a more detailed explanation, see the Exception Entry Behavior
> + * section of the ARMv7M Architecture Reference Manual.
> + */
> +
> +/* As we're in Handler mode here, we'll always operate on MSP.
> + * However, we need to store the right SP in our CPU_Exception_frame.
> + */
>__asm__ volatile (
> -"sub sp, %[cpufsz]\n"
> +"sub sp, %[cpufsz]\n" /* Allocate space for a CPU_Exception_frame. */
>  "stm sp, {r0-r12}\n"
> -"mov r2, lr\n"
> -"mrs r1, msp\n"
> -"mrs r0, psp\n"
> -"cmn r2, #3\n"
> -"itt ne\n"
> -"movne r0, r1\n"
> -"addne r0, %[cpufsz]\n"
> +"tst lr, #4\n"   /* Check if bit 2 of LR is zero. (If so, PSR.Z = 1) 
> */
> +"itte eq\n"  /* IF bit 2 of LR is zero... (PSR.Z == 1) */
> +"mrseq r0, msp\n"/* THEN we were using MSP. */
> +"addeq r0, %[cpufsz]\n" /* THEN, set r0 = old MSP. */
> +"mrsne r0, psp\n"/* ELSE it's not zero; we were using PSP. */
>  "add r2, r0, %[v7mlroff]\n"
>  "add r1, sp, %[cpulroff]\n"
>  "ldm r2, {r3-r5}\n"
> --
> 1.9.1



-- 

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

Re: [PATCH v3] ARMv7M: Fix exception handler for supporting FPU

[Daniel Gutson]

On Mon, Aug 31, 2015 at 2:34 PM, Gedare Bloom <ged...@rtems.org> wrote:
> I'd approve 2 patches in case you want to give credit. First patch
> with Sudarshan's fix, and Martin's improvement second.

+1

>
> On Mon, Aug 31, 2015 at 1:28 PM, Daniel Gutson
> <daniel.gut...@tallertechnologies.com> wrote:
>> Side question to Joel and others: is this enough to credit Sudarshan?
>> He did an amazing job for finding the bug and proposing an initial
>> solution.
>>
>> On Mon, Aug 31, 2015 at 11:37 AM, Martin Galvan
>> <martin.gal...@tallertechnologies.com> wrote:
>>> On exception entry, _ARMV7M_Exception_default stores the previous Stack 
>>> Pointer
>>> in a CPU_Exception_frame. The SP can be MSP or PSP, depending on the mode
>>> in which the exception was taken. To know this, we must check the value of 
>>> LR.
>>>
>>> Right now the code checks whether it should store MSP or PSP by comparing 
>>> LR to
>>> -3. However, this doesn't work if we're using an FPU. This patch fixes that
>>> by checking bit 2 of LR, which indicates which SP we were using.
>>>
>>> Thanks to Sudarshan Rajagopalan for finding the bug and proposing a first
>>> version of the fix.
>>>
>>> Closes #2401.
>>>
>>> ---
>>>  cpukit/score/cpu/arm/armv7m-exception-default.c | 27 
>>> +
>>>  1 file changed, 19 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/cpukit/score/cpu/arm/armv7m-exception-default.c 
>>> b/cpukit/score/cpu/arm/armv7m-exception-default.c
>>> index e890cdf..d04dbea 100644
>>> --- a/cpukit/score/cpu/arm/armv7m-exception-default.c
>>> +++ b/cpukit/score/cpu/arm/armv7m-exception-default.c
>>> @@ -22,16 +22,27 @@
>>>
>>>  void __attribute__((naked)) _ARMV7M_Exception_default( void )
>>>  {
>>> +/* On exception entry, ARMv7M saves context state onto a stack pointed 
>>> to
>>> + * by either MSP or PSP. The value stored in LR indicates whether we 
>>> were
>>> + * in Thread or Handler mode, whether we were using the FPU (if any),
>>> + * and which stack pointer we were using.
>>> + * In particular, bit 2 of LR will be 0 if we were using MSP.
>>> + *
>>> + * For a more detailed explanation, see the Exception Entry Behavior
>>> + * section of the ARMv7M Architecture Reference Manual.
>>> + */
>>> +
>>> +/* As we're in Handler mode here, we'll always operate on MSP.
>>> + * However, we need to store the right SP in our CPU_Exception_frame.
>>> + */
>>>__asm__ volatile (
>>> -"sub sp, %[cpufsz]\n"
>>> +"sub sp, %[cpufsz]\n" /* Allocate space for a CPU_Exception_frame. */
>>>  "stm sp, {r0-r12}\n"
>>> -"mov r2, lr\n"
>>> -"mrs r1, msp\n"
>>> -"mrs r0, psp\n"
>>> -"cmn r2, #3\n"
>>> -"itt ne\n"
>>> -"movne r0, r1\n"
>>> -"addne r0, %[cpufsz]\n"
>>> +"tst lr, #4\n"   /* Check if bit 2 of LR is zero. (If so, PSR.Z = 
>>> 1) */
>>> +"itte eq\n"  /* IF bit 2 of LR is zero... (PSR.Z == 1) */
>>> +"mrseq r0, msp\n"/* THEN we were using MSP. */
>>> +"addeq r0, %[cpufsz]\n" /* THEN, set r0 = old MSP. */
>>> +"mrsne r0, psp\n"/* ELSE it's not zero; we were using PSP. */
>>>  "add r2, r0, %[v7mlroff]\n"
>>>  "add r1, sp, %[cpulroff]\n"
>>>  "ldm r2, {r3-r5}\n"
>>> --
>>> 1.9.1
>>
>>
>>
>> --
>>
>> 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



-- 

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

Re: cppcheck errors

[Daniel Gutson]

On Thu, Aug 27, 2015 at 6:38 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:


 On 8/27/2015 4:15 PM, Martin Galvan wrote:

 On Thu, Aug 27, 2015 at 6:10 PM, Daniel Gutson
 daniel.gut...@tallertechnologies.com wrote:

 Maybe we can just provide the list until we provide the fixes? Martín?


 Gladly. Keep in mind we ran cppcheck only on the modules we use
 (though some things may've slipped in, like nios):


 Most of these are worth looking at. Honestly, the ones on the tcp/ip
 stack and other directly imported code aren't going to get touched.

 [c/src/lib/libbsp/shared/umon/umon.h:21]: (error) Invalid number of
 character ({) when these macros are defined: '__cplusplus'.


 Spot check shows this is missing the closing magic for extern C.
 I see a couple more of these below and we should fix though.

 [cpukit/libmisc/dumpbuf/dumpbuf.c:69]: (error) Undefined behavior:
 Variable 'line_buffer' is used as parameter and destination in
 s[n]printf().
 [cpukit/libmisc/dumpbuf/dumpbuf.c:76]: (error) Undefined behavior:
 Variable 'line_buffer' is used as parameter and destination in
 s[n]printf().


 This should be looked at.

 [cpukit/libmisc/stackchk/check.c:285] -
 [cpukit/libmisc/stackchk/check.c:294]: (performance) Variable
 'pattern_ok' is reassigned a value before the old one has been used.


 This should be looked at.

 [cpukit/libmisc/stackchk/check.c:255]: (portability) 'pattern_area' is
 of type 'void *'. When using void pointers in calculations, the
 behaviour is undefined.


 Not sure what to do about this. I think this is defined behavior
 for at least GCC.

This is because + and - operators are not defined for void*, since

addr(pointer + k) = addr(pointer) + k * sizeof(*pointer),

but since pointer is void*, sizeof(void) is not defined, that's why it
is non-standard. However, gcc extensions
considers this case as char*, which is exactly the way to make this
portable: just cast it to char* before doing the arithmetics.



 [cpukit/libnetworking/kern/kern_subr.c:93]: (portability) 'cp' is of
 type 'void *'. When using void pointers in calculations, the behaviour
 is undefined.
 [cpukit/libnetworking/kern/uipc_socket2.c:616]: (error) Uninitialized
 variable: o


 Imported code.

At the end it goes to the same binary, no matter where it came from,
so IMHO it may be worth
to send a patch to where this comes from.


 [cpukit/libnetworking/lib/ftpfs.c:704] -
 [cpukit/libnetworking/lib/ftpfs.c:709]: (performance) Variable
 'port_socket' is reassigned a value before the old one has been used.
 [cpukit/libnetworking/lib/tftpDriver.c:503]: (error) Common realloc
 mistake: 'current' nulled but not freed upon failure


 Need to be looked at.

 [cpukit/libnetworking/libc/ether_addr.c:72]: (portability) scanf
 without field width limits can crash with huge input data on some
 versions of libc.
 [cpukit/libnetworking/libc/ether_addr.c:94]: (portability) scanf
 without field width limits can crash with huge input data on some
 versions of libc.
 [cpukit/libnetworking/libc/gethostbyht.c:233]: (error) Common realloc
 mistake: 'hostmap' nulled but not freed upon failure
 [cpukit/libnetworking/libc/ns_addr.c:112]: (portability) scanf without
 field width limits can crash with huge input data on some versions of
 libc.
 [cpukit/libnetworking/libc/ns_addr.c:120]: (portability) scanf without
 field width limits can crash with huge input data on some versions of
 libc.
 [cpukit/libnetworking/libc/ns_addr.c:128]: (portability) scanf without
 field width limits can crash with huge input data on some versions of
 libc.
 [cpukit/libnetworking/libc/ns_addr.c:137]: (portability) scanf without
 field width limits can crash with huge input data on some versions of
 libc.


 All imported code. maybe the realloc() is worth addressing.

 [cpukit/libnetworking/rtems/rtems_dhcp.c:401]: (error) Common realloc
 mistake: 'dhcp_hostname' nulled but not freed upon failure


 This is the only one in our code.

 [cpukit/librpc/src/rpc/netnamer.c:331]: (error) Resource leak: fd


 Probably should be looked at.

 [cpukit/posix/include/rtems/posix/ptimer.h:33]: (error) Invalid number
 of character ({) when these macros are defined: '__cplusplus'.
 [cpukit/rtems/include/rtems/rtems/dpmemimpl.h:116]: (error) Invalid
 number of character ({) when these macros are defined: '__cplusplus'.


 Easy.

 [cpukit/score/cpu/h8300/cpu.c:54]: (error) Uninitialized variable:
 _ccr (si no se inicializa, se hace un #warning pero igual existe el
 problema)


 Appears to be confused by conditional or inline asm.

 [cpukit/zlib/gzwrite.c:80]: (error) Uninitialized variable: got


 Hmm.. but third party code.

 [tools/build/binpatch.c:104]: (error) Resource leak: ifp
 [tools/build/binpatch.c:63]: (error) Uninitialized variable: off
 [tools/build/unhex.c:238]: (error) Resource leak: outfp


 Need to be looked at but these are host side utilities. There is likely
 no resource leak since it is a process. The unitialized variable needs
 looking at. We fixed a number

Re: [PATCH] Fix exception handler for supporting FPU

[Daniel Gutson]

On Fri, Aug 28, 2015 at 12:20 PM, Gedare Bloom ged...@gwu.edu wrote:
 Could you please open a ticket on our trac to describe the problem
 this fixes, and add closes #. to your patch commit message?

Additionally, please clarify which architecture this applies to. I
suspect this is for cortex-m4.
In any case, please clarify which architectures you tested on. We can
analyze and test cortex-m3 if you don't have one.


 Thanks,
 Gedare

 On Thu, Aug 27, 2015 at 4:33 PM, sudarshan.rajagopalan
 sudarshan.rajagopa...@vecna.com wrote:
 Patch attached here for ARMv7M Exception Handler. Looks like git send-email
 didn't deliver the mail. Something is not quite right with our mail server
 here. Avoid this email if patch delivered through git.

 Thanks and Regards,

 Sudarshan




 ___
 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

Re: ARMv7M Exception Handler

[Daniel Gutson]

On Fri, Aug 28, 2015 at 12:33 PM, sudarshan.rajagopalan
sudarshan.rajagopa...@vecna.com wrote:
 On 2015-08-27 17:06, Joel Sherrill wrote:

 On 8/27/2015 3:58 PM, Daniel Gutson wrote:

 On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan
 sudarshan.rajagopa...@vecna.com wrote:

 Hey guys,

 I was working on the exception handler for the CPU hard fault. Managed
 to
 register the fatal error user extension to RTEMS and call the user
 defined
 function when an exception occurs. But the pointer to the stacked frame
 didn't have the correct register values(esp. the PC register). So I
 looked
 into the assembly code in
 /cpukit/score/cpu/arm/armv7m-exception-default.c,
 where it decides which stack pointer was used (MSP or PSP) before the
 exception occurred depending on the error code returned in the Link
 Register. After carefully examining all the assembly instructions, I
 guess
 theres a little bug in the code.

 The instruction cmn r2, #3\n in line 31 basically compares the Link
 Register(lr) to value 0xFFFD (negative #3, because CMN negates the
 RHS
 and compares with LHS) and chooses MSP or PSP in the following IT block.
 This is pretty cool! But, it will not work if you have the
 floating-point
 unit (FPU) enabled in your processor, which is enabled in mine. With FPU
 enabled, the error code returned is either 0xFFE9 or 0xFFED, for
 which the above assembly instruction will not work out and MSP will be
 selected always.

 Better way to do is to check the 2nd bit of the error code to determine
 which stack pointer was used before the exception happened - tst lr,
 #4\n
 and change the IT block from itt ne to itt eq and the mov and
 add
 within this IT block.

 Have tested this with the above changes and it works. I have sent the
 patch
 0001-Fix-exception-handler-for-supporting-FPU.patch to the devel
 mailing
 list that fixes this problem. :)


 Nice. Have you tested this without FPU support too?


 Hi Daniel,

 Just tested the fix with FPU disabled in my processor and it works fine.
 This patch can be pushed!

As I mentioned before, please mention what architecture you tested
(what use cases) and which you didn't.


 Daniel .. when you are happy, we can push it.

 Should this go on the 4.11 branch and master? If so, it needs a ticket.


 Joel, I think this fix is vital and should be pushed to master. Will make a
 ticket for this.

 Thanks and Regards,

 Sudarshan
 --
 Sudarshan Rajagopalan
 sudarshan.rajagopalan at vecna.com
 www.vecna.com


 Thanks and Regards,
 Sudarshan
 ___
 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

Re: [PATCH] Fix exception handler for supporting FPU

[Daniel Gutson]

On Fri, Aug 28, 2015 at 2:31 PM, sudarshan.rajagopalan
sudarshan.rajagopa...@vecna.com wrote:
 On 2015-08-28 12:18, sudarshan.rajagopalan wrote:

 On 2015-08-28 11:30, Daniel Gutson wrote:

 On Fri, Aug 28, 2015 at 12:20 PM, Gedare Bloom ged...@gwu.edu wrote:

 Could you please open a ticket on our trac to describe the problem
 this fixes, and add closes #. to your patch commit message?


 Hi Gedare, Sure will do!


 Additionally, please clarify which architecture this applies to. I
 suspect this is for cortex-m4.
 In any case, please clarify which architectures you tested on. We can
 analyze and test cortex-m3 if you don't have one.


 Daniel, I've tested it on Cortex-M4 but this patch should also apply
 to Cortex-M3 or all ARMv7M based processor (including M7). But please
 feel free to test it on Cortex-M3 since I don't have it with me now.

 Am also attaching the links to ARM Cortex-M3, M4 and M7 Exception
 entry and return referenece documents for a quick reference, where the
 table gives all the possible exception error codes returned and which
 SP to pick depending on the error code. The only tricky part would be
 error code: 0xFFE1. But the asm tst.w lr, #4 with lr=0xFFE1
 will result into zero and will set the Zero flag, which will make the
 ITT EQ block execute, which will choose MSP, which it should for the
 return code 0xFFE1 (or even 0xFFF1) in all M3, M4 and M7. But
 please feel free to test it on real M3 an M7 processor. I have tested
 it by manually giving all the return error codes for M3 and M7 to LR
 and and it chooses the right SP value.

 ARM Reference Docs - Exception Entry and Return:
 C-3:

 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Babefdjc.html
 C-4:

 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Babefdjc.html
 C-7:

 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/Babefdjc.html

 Thanks and Regards,
 Sudarshan



 Ok, so we tested the fix on Cortex-M7 processor. The error codes for C-4 and
 C-7 are all pretty much the same. This leaves with C-3, which I believe
 should work too, becasue non-FPU error codes are same for C-3, C-4 and C-7.

Hi Sudarshan,

   ok thanks. We will comment on Monday since we have a release today.

Good job.

   Daniel.


 Thanks,

 Sudarshan




 Thanks,
 Gedare

 On Thu, Aug 27, 2015 at 4:33 PM, sudarshan.rajagopalan
 sudarshan.rajagopa...@vecna.com wrote:

 Patch attached here for ARMv7M Exception Handler. Looks like git
 send-email
 didn't deliver the mail. Something is not quite right with our mail
 server
 here. Avoid this email if patch delivered through git.

 Thanks and Regards,

 Sudarshan




 ___
 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


 ___
 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

Re: ARMv7M Exception Handler

[Daniel Gutson]

On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan
sudarshan.rajagopa...@vecna.com wrote:
 Hey guys,

 I was working on the exception handler for the CPU hard fault. Managed to
 register the fatal error user extension to RTEMS and call the user defined
 function when an exception occurs. But the pointer to the stacked frame
 didn't have the correct register values(esp. the PC register). So I looked
 into the assembly code in /cpukit/score/cpu/arm/armv7m-exception-default.c,
 where it decides which stack pointer was used (MSP or PSP) before the
 exception occurred depending on the error code returned in the Link
 Register. After carefully examining all the assembly instructions, I guess
 theres a little bug in the code.

 The instruction cmn r2, #3\n in line 31 basically compares the Link
 Register(lr) to value 0xFFFD (negative #3, because CMN negates the RHS
 and compares with LHS) and chooses MSP or PSP in the following IT block.
 This is pretty cool! But, it will not work if you have the floating-point
 unit (FPU) enabled in your processor, which is enabled in mine. With FPU
 enabled, the error code returned is either 0xFFE9 or 0xFFED, for
 which the above assembly instruction will not work out and MSP will be
 selected always.

 Better way to do is to check the 2nd bit of the error code to determine
 which stack pointer was used before the exception happened - tst lr, #4\n
 and change the IT block from itt ne to itt eq and the mov and add
 within this IT block.

 Have tested this with the above changes and it works. I have sent the patch
 0001-Fix-exception-handler-for-supporting-FPU.patch to the devel mailing
 list that fixes this problem. :)

Nice. Have you tested this without FPU support too?


 Thanks and Regards,
 Sudarshan
 ___
 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

Re: cppcheck errors

[Daniel Gutson]

On Thu, Aug 27, 2015 at 6:06 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:


 On 8/13/2015 10:52 AM, Daniel Gutson wrote:


 El 13/8/2015 12:49, Gedare Bloom ged...@gwu.edu
 mailto:ged...@gwu.edu escribió:
  
   Daniel,
  
   Unknown deadline right now. Probably whenever Joel can get around to
   it! Realistically, we can create a bugfix dot release anytime after
   the release subject to user demand. So, even if you miss the 4.11.0
   release with your patches, we can cut a 4.11.1 after applying the
   patches if you need an official release to work from.

 Ok. Yes, we do.

 Thanks. Anyway we're making a ranking for a timebox of 2 weeks.


 Any updates?

Sorry guys, we have a release tomorrow (which contains some of the top
fixes) but didn't have the time
to send a patch. We will send it early next week.
FWIW, nios had memory leaks but since we are not using that arch we skipped it.
Maybe we can just provide the list until we provide the fixes? Martín?


   Gedare
  
   On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson
   daniel.gut...@tallertechnologies.com
 mailto:daniel.gut...@tallertechnologies.com wrote:
Hi Gedare,
   
What's the deadline for the official release, if any?
   
El 13/8/2015 7:15, Gedare Bloom ged...@gwu.edu
 mailto:ged...@gwu.edu escribió:
   
Daniel,
   
The release has (unofficially) happened on rtems.git/4.11 branch,
 from
which master is slowly diverging. Any patches you want applied
 before
the official release need to be (1) associated with a ticket on
 Trac,
and (2) apply to both the 4.11 and master branches.
   
Gedare
   
On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com
 mailto:daniel.gut...@tallertechnologies.com wrote:
 Hi guys,

   we will be posting patches for a number of errors reported by
 cppcheck (errors that we can confirm are not false positives).
 Please hold on any release.

Daniel.

 --

 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 mailto:devel@rtems.org
 http://lists.rtems.org/mailman/listinfo/devel


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



-- 

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

Re: Porting CANFestival to RTEMS

[Daniel Gutson]

On Wed, Aug 19, 2015 at 1:51 PM, Isaac Gutekunst
isaac.guteku...@vecna.com wrote:
 Hi

 I'm thinking about porting CANFestival to RTEMS. I think it should be
 relatively doable do to the posix support, and because the core files don't
 have any platform specific code as far as I can tell.

 Has anyone had any experience porting CANFestival so far, are could offer
 some advice?

FWIW, we have CANAerospace running on BeagleBone Black and LPC1768.
I don't recall anything special about it.


 So far I've made a copy of the UNIX time and lincan drivers and renamed them
 to can_rtems and timers_rtems as well as a couple of other directories.

 I've gotten to the point where I need to link against an RTEMS BSP, and
 don't really know what to do. I want to include rtems.h and generate a
 static library that I can link with my application, or if I'm really lucky,
 run the existing examples on RTEMS.

 Regarding CAN drivers, I have written a simplistic CAN driver framework
 based on lincan and the current cpukit/dev/i2c style IMFS driver. This
 should be easy to support in CANFestival, and could pave the way for
 supporting lincan directly at some point.


 Thanks,

 Isaac
 ___
 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

Re: Identify control statements in source code

[Daniel Gutson]

El 13/8/2015 19:35, Joel Sherrill joel.sherr...@oarcorp.com escribió:



 On August 13, 2015 3:34:12 PM CDT, Daniel Gutson 
daniel.gut...@tallertechnologies.com wrote:
 I'd recommend a gcc plugin that generates your annotations; otherwise,
 dig into gcov in order to parse a .gcno file.

 Covoar already produces gcov files. A previous gsoc student did that.
This was a bonus task and we were never 100% confident in the gcov files
produced.

He needs a static analysis tool. Is covoar the case?


 I would recommend pulling this thread. Produce the normal gcc coverage
files, use covoar to produce gcov files, and then run gcov on the results.
Compare to what covoar reports and address discrepancies.

 On Thu, Aug 13, 2015 at 5:09 PM, Hermann Felbinger
 hermann19...@gmail.com wrote:
  I am looking for something that processes the source code at compile
 time. I
  need this information to map branches from execution traces to
 conditions
  within the source code. With this information it will be possible to
 analyze
  source coverage metrics as decision coverage or MCDC.
 
 
  Daniel Gutson daniel.gut...@tallertechnologies.com schrieb am Do.,
 13.
  Aug. 2015 um 21:50 Uhr:
 
  1) Are you looking for something statically processed (i.e. at
 compile
  time) or at runtime? (such as gcov)
  2) Are you looking for a way to add _your_ annotations, or a way to
  _extract_ information?
 
  In any case, the best way I can think of is with a gcc plugin.
 
  Have you seen gcc's -ftest-coverage option?
 
 Daniel.
 
  On Thu, Aug 13, 2015 at 4:06 PM, Hermann Felbinger
  hermann19...@gmail.com wrote:
   Hi all!
  
   I am working on a tool to analyze source code coverage for RTEMS.
   Currently I am looking for a tool to annotate source code such
 that I
   can
   extract information about statements and conditions that affect
 the
   control
   flow of a program.
   A similar tool exists for Ada programs. They call this information
   'Source
   Coverage Obligations'. Some information about SCOs can be found in
 [1].
   I attached a program triangle.c which contains some if-statements.
 Each
   of
   these statements contains two or more conditions. The second
 attached
   file
   is the output of compiling triangle.c with
   gcc -O1 -fdump-tree-cfg -o triangle triangle.c
   This output is almost what I am looking for, but I think that
 there has
   to
   be something better out there.
  
   Does anybody of you know a tool which I can use to annotate source
 code?
  
   Best,
   Hermann
  
   [1] http://docs.adacore.com/gnatcoverage-docs/html/cov_source.html
  
   ___
   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
 
 
 
 --
 
 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

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

Re: Identify control statements in source code

[Daniel Gutson]

1) Are you looking for something statically processed (i.e. at compile
time) or at runtime? (such as gcov)
2) Are you looking for a way to add _your_ annotations, or a way to
_extract_ information?

In any case, the best way I can think of is with a gcc plugin.

Have you seen gcc's -ftest-coverage option?

   Daniel.

On Thu, Aug 13, 2015 at 4:06 PM, Hermann Felbinger
hermann19...@gmail.com wrote:
 Hi all!

 I am working on a tool to analyze source code coverage for RTEMS.
 Currently I am looking for a tool to annotate source code such that I can
 extract information about statements and conditions that affect the control
 flow of a program.
 A similar tool exists for Ada programs. They call this information 'Source
 Coverage Obligations'. Some information about SCOs can be found in [1].
 I attached a program triangle.c which contains some if-statements. Each of
 these statements contains two or more conditions. The second attached file
 is the output of compiling triangle.c with
 gcc -O1 -fdump-tree-cfg -o triangle triangle.c
 This output is almost what I am looking for, but I think that there has to
 be something better out there.

 Does anybody of you know a tool which I can use to annotate source code?

 Best,
 Hermann

 [1] http://docs.adacore.com/gnatcoverage-docs/html/cov_source.html

 ___
 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

Re: Identify control statements in source code

[Daniel Gutson]

I'd recommend a gcc plugin that generates your annotations; otherwise,
dig into gcov in order to parse a .gcno file.

On Thu, Aug 13, 2015 at 5:09 PM, Hermann Felbinger
hermann19...@gmail.com wrote:
 I am looking for something that processes the source code at compile time. I
 need this information to map branches from execution traces to conditions
 within the source code. With this information it will be possible to analyze
 source coverage metrics as decision coverage or MCDC.


 Daniel Gutson daniel.gut...@tallertechnologies.com schrieb am Do., 13.
 Aug. 2015 um 21:50 Uhr:

 1) Are you looking for something statically processed (i.e. at compile
 time) or at runtime? (such as gcov)
 2) Are you looking for a way to add _your_ annotations, or a way to
 _extract_ information?

 In any case, the best way I can think of is with a gcc plugin.

 Have you seen gcc's -ftest-coverage option?

Daniel.

 On Thu, Aug 13, 2015 at 4:06 PM, Hermann Felbinger
 hermann19...@gmail.com wrote:
  Hi all!
 
  I am working on a tool to analyze source code coverage for RTEMS.
  Currently I am looking for a tool to annotate source code such that I
  can
  extract information about statements and conditions that affect the
  control
  flow of a program.
  A similar tool exists for Ada programs. They call this information
  'Source
  Coverage Obligations'. Some information about SCOs can be found in [1].
  I attached a program triangle.c which contains some if-statements. Each
  of
  these statements contains two or more conditions. The second attached
  file
  is the output of compiling triangle.c with
  gcc -O1 -fdump-tree-cfg -o triangle triangle.c
  This output is almost what I am looking for, but I think that there has
  to
  be something better out there.
 
  Does anybody of you know a tool which I can use to annotate source code?
 
  Best,
  Hermann
 
  [1] http://docs.adacore.com/gnatcoverage-docs/html/cov_source.html
 
  ___
  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



-- 

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

Re: cppcheck errors

[Daniel Gutson]

El 13/8/2015 12:49, Gedare Bloom ged...@gwu.edu escribió:

 Daniel,

 Unknown deadline right now. Probably whenever Joel can get around to
 it! Realistically, we can create a bugfix dot release anytime after
 the release subject to user demand. So, even if you miss the 4.11.0
 release with your patches, we can cut a 4.11.1 after applying the
 patches if you need an official release to work from.

Ok. Yes, we do.

Thanks. Anyway we're making a ranking for a timebox of 2 weeks.


 Gedare

 On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson
 daniel.gut...@tallertechnologies.com wrote:
  Hi Gedare,
 
  What's the deadline for the official release, if any?
 
  El 13/8/2015 7:15, Gedare Bloom ged...@gwu.edu escribió:
 
  Daniel,
 
  The release has (unofficially) happened on rtems.git/4.11 branch, from
  which master is slowly diverging. Any patches you want applied before
  the official release need to be (1) associated with a ticket on Trac,
  and (2) apply to both the 4.11 and master branches.
 
  Gedare
 
  On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson
  daniel.gut...@tallertechnologies.com wrote:
   Hi guys,
  
 we will be posting patches for a number of errors reported by
   cppcheck (errors that we can confirm are not false positives).
   Please hold on any release.
  
  Daniel.
  
   --
  
   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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Porting Linux driver into Xtratum

[Daniel Gutson]

Are you intending to make RTEMS use an existing linux driver via
Xtratum? Otherwise, which is the relationship with RTEMS?

On Sun, Aug 9, 2015 at 11:26 AM, Shabnam Engineer
shabnam.enginee...@yahoo.com wrote:
 Hello,
 I have a question about porting Linux drivers into Xtratum.
 Can I port Linux drivers into Xtratum? or is there something like DDE/DDEKit
 (it is for l4-based systems) for Xtratum.
 I want to implement Xtratum on a board and test some features, At first I
 want to  be sure that if I need a driver for our special tests that is not
 in Xtratum package, Could I choose it from Linux drivers and port it into
 Xtratum hypervisor?

 Thank you for your considering my question.
 Regards,
 Shabnam

 ___
 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

Re: RTEMS lwIP porting

[Daniel Gutson]

On Mon, Aug 10, 2015 at 10:48 AM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:


 On 8/9/2015 4:57 AM, ragu nath wrote:

 Hi All,

 I have sent the patches for building lwIP from RSB.  First patch
 contains changes for RTEMS Resource Builder. The second patch is RTEMS
 specific changes that will be applied to lwIP base.This patch contains
 only lwIP sources. I will be sending another patch for the driver to
 be used with lwIP. The application can then link to both of the
 libararies (lwip  driver).


 Has the LWIP patch been submitted upstream to the LWIP maintainers?

 And where do drivers come from? From what I have seen, LWIP seems
 to not have a unified base of device drivers. Would this just be to
 build the basic stack and then it is the users responsibility to
 find and compile a driver?

Also, what from these comes from our work? Sorry that I'm a little bit
confused and arrived late to the
subject. BTW, there is still work to do, since the state we left
working LWIP is using the posix layer,
which we observed introduces important overhead, so a further step is
to reimplement the LWIP's HAL
using the RTEMS native API instead. Any plan for that?

Thanks!

Daniel.


 What is your RTEMS configuration so I can try it?

 I will try to build it today.

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



-- 

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

Re: RTEMS lwIP porting

[Daniel Gutson]

El 10/8/2015 14:25, ragu nath ragunath3...@gmail.com escribió:

 Hi Daniel,

 Most of the  work comes from  your/marcos port.

Roger that.

  The aim was to
 integrate a working lwIP port to RTEMS Source Builder.
 I took the port  understood what has been done. Then I wrote  an
 application that uses lwip stack on RTEMS.
 I ran into some issues and fixed them.

Did you post them? (Marcos, are we aware of such bugs and fixes? I am very
interested about this matter).

 Now with the changes,  the
 application works.

 I discussed with chris on how to integrate the changes to RSB. As per
 his suggestion, the idea is to separate lwip base and drivers. The
 lwip base is compiled as a library using RSB and driver will be
 compiled as a separate library .  The application can then link to it.
 The driver is also from your port with some fixes.

 I am not aware of the issue with POSIX API. Once we get this working,
 I am ready to implement with native api in the future.


 Thanks,
 Ragunath


 On Mon, Aug 10, 2015 at 9:50 PM, Daniel Gutson
 daniel.gut...@tallertechnologies.com wrote:
  On Mon, Aug 10, 2015 at 10:48 AM, Joel Sherrill
  joel.sherr...@oarcorp.com wrote:
 
 
  On 8/9/2015 4:57 AM, ragu nath wrote:
 
  Hi All,
 
  I have sent the patches for building lwIP from RSB.  First patch
  contains changes for RTEMS Resource Builder. The second patch is RTEMS
  specific changes that will be applied to lwIP base.This patch contains
  only lwIP sources. I will be sending another patch for the driver to
  be used with lwIP. The application can then link to both of the
  libararies (lwip  driver).
 
 
  Has the LWIP patch been submitted upstream to the LWIP maintainers?
 
  And where do drivers come from? From what I have seen, LWIP seems
  to not have a unified base of device drivers. Would this just be to
  build the basic stack and then it is the users responsibility to
  find and compile a driver?
 
  Also, what from these comes from our work? Sorry that I'm a little bit
  confused and arrived late to the
  subject. BTW, there is still work to do, since the state we left
  working LWIP is using the posix layer,
  which we observed introduces important overhead, so a further step is
  to reimplement the LWIP's HAL
  using the RTEMS native API instead. Any plan for that?
 
  Thanks!
 
  Daniel.
 
 
  What is your RTEMS configuration so I can try it?
 
  I will try to build it today.
 
  --
  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
 
 
 
  --
 
  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



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

Re: Nice surprise with C++11

[Daniel Gutson]

On Fri, Jul 31, 2015 at 9:56 AM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:


 On 31/07/15 14:51, Daniel Gutson wrote:


  Is it possible to construct objects without an address via plain C++?

 Sorry I don't understand the question. Rephrase please?

 Global objects and objects of static storage duration don't take an
 address.


 This register asm variable has no address, since this is a real register.
 This, however, is not a problem:

 int *h(void)
 {
 register int i;
 return i;

 }

The 'register' keyword is deprecated since C++11.
Additionally, C++ requires that all objects have unique addresses, that's why
struct X{};
sizeof(X)  0

(and that's why the empty ase class optimization idiom exists).

Moreover, taking the address of an object prevents such object to
dwell in a register.

In your example, even in previous C++ versions, should prevent the
'register' hint to be honored,
thus returning a temporal address to the stack (which would be invalid
in the caller's context).

So the short answer is NO.

Did I answer your question? Is there any case this should be possible?
(consider that I'm pursuing
new C++ features for embedded systems in the C++ committee).

   Daniel.


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




-- 

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

Re: Nice surprise with C++11

[Daniel Gutson]

El 31/7/2015 2:37, Sebastian Huber sebastian.hu...@embedded-brains.de
escribió:

 Hello Daniel,

Hello Sebastian.



 On 30/07/15 17:26, Daniel Gutson wrote:

 On Thu, Jul 30, 2015 at 11:31 AM, Daniel Gutson
 daniel.gut...@tallertechnologies.com  wrote:

 
 El 30/7/2015 11:27, Joel Sherrilljoel.sherr...@oarcorp.com
escribió:

 
 
 
 On 7/30/2015 9:08 AM, Daniel Gutson wrote:

 
 IOW, I think that the double parens is only for decltype.

 
 
 Historical convention is to put parens around variable names
 in macros. What type of impact does this have?

 
 If what I think is correct, then the impact os none since this a bug.
But I
 will look at it deeper once I arrive to the office in 1h. I will try
with
 different versions of gcc and clang and look into the C++ standard. So
far
 the (()) seems to be a decltype only thing, so this would be a
frontend bug.

 As I mentioned in the bugzilla, I think this is a bug of the front-end
 (since I could not reproduce
 it in earlier versions of g++ (4.8.4) and clang (3.5)). I already
 asked Ville Voutilainen and Jens Maurer
 (from the C++ Committee) to look into it. I will let you know.


 thanks for looking at this issue. Is this really a problem within the
scope of the standard?

The bug has been introduced when implementing the new rules related to
decltype in C++14. Indeed the code has something like 'if (cxxversion 
CPP14) return;' meaning that the newly (faulty) introduced code is not
executed when running previous std versions: that's why -std=c++11 should
work (the problem is that g++ 6 defaults to c++14).

The global register variables are GCC specific.

Yes, a GNU C extension.

 Is it possible to construct objects without an address via plain C++?

Sorry I don't understand the question. Rephrase please?

Global objects and objects of static storage duration don't take an address.



 --
 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: Nice surprise with C++11

[Daniel Gutson]

IOW, I think that the double parens is only for decltype.
El 30/7/2015 11:06, escribió:

 I don't it's a language issue: https://ideone.com/k1vz5d
  El 30/7/2015 10:51, Gedare Bloom ged...@gwu.edu escribió:

 OK, I guess this makes the convention minimize parentheses mandatory
 if we want C++11. I guess the basic problem is that constructions
 where a single atom is in parens may produce different results now. At
 least an error is emitted rather than silent optimization..

 -Gedare

 On Thu, Jul 30, 2015 at 2:49 AM, Sebastian Huber
 sebastian.hu...@embedded-brains.de wrote:
  Hello,
 
  please have a look at the following bug:
 
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
 
  This is really nice in combination with defines and macros that use ( )
 to
  make sure the content stays together.
 
  --
  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


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

Re: Nice surprise with C++11

[Daniel Gutson]

I don't it's a language issue: https://ideone.com/k1vz5d
 El 30/7/2015 10:51, Gedare Bloom ged...@gwu.edu escribió:

 OK, I guess this makes the convention minimize parentheses mandatory
 if we want C++11. I guess the basic problem is that constructions
 where a single atom is in parens may produce different results now. At
 least an error is emitted rather than silent optimization..

 -Gedare

 On Thu, Jul 30, 2015 at 2:49 AM, Sebastian Huber
 sebastian.hu...@embedded-brains.de wrote:
  Hello,
 
  please have a look at the following bug:
 
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
 
  This is really nice in combination with defines and macros that use ( )
 to
  make sure the content stays together.
 
  --
  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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Nice surprise with C++11

[Daniel Gutson]

El 30/7/2015 11:27, Joel Sherrill joel.sherr...@oarcorp.com escribió:



 On 7/30/2015 9:08 AM, Daniel Gutson wrote:

 IOW, I think that the double parens is only for decltype.


 Historical convention is to put parens around variable names
 in macros. What type of impact does this have?

If what I think is correct, then the impact os none since this a bug. But I
will look at it deeper once I arrive to the office in 1h. I will try with
different versions of gcc and clang and look into the C++ standard. So far
the (()) seems to be a decltype only thing, so this would be a frontend bug.


 El 30/7/2015 11:06, escribió:

 I don't it's a language issue: https://ideone.com/k1vz5d

 El 30/7/2015 10:51, Gedare Bloom ged...@gwu.edu mailto:
ged...@gwu.edu escribió:

 OK, I guess this makes the convention minimize parentheses
mandatory
 if we want C++11. I guess the basic problem is that constructions
 where a single atom is in parens may produce different results
now. At
 least an error is emitted rather than silent optimization..

 -Gedare

 On Thu, Jul 30, 2015 at 2:49 AM, Sebastian Huber
 sebastian.hu...@embedded-brains.de mailto:
sebastian.hu...@embedded-brains.de wrote:
   Hello,
  
   please have a look at the following bug:
  
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
  
   This is really nice in combination with defines and macros
that use ( ) to
   make sure the content stays together.
  
   --
   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 mailto:
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 mailto:devel@rtems.org

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


 --
 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: CMSIS?

[Daniel Gutson]

Hi guys,

   I just got a student who likes this project and wants to provide a
CMSIS API to RTEMS as her career final project.
I will be her director.
Besides telling her to read stuff, documentation, and the github
source files, any initial advice about how to implement this
on top of RTEMS? I.e. an external library with RSB support?

  Daniel.

On Wed, Sep 3, 2014 at 11:36 AM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
 I hate to reply to my own post but need to in this case.

 https://mbed.org/blog/entry/CMSIS-Components-BSD-Licensed/

 Code is available and BSD licensed. Last comment gives link to
 blog making code available.

 We weren't the only ones with a problem with their license.
 On 9/3/2014 9:30 AM, Joel Sherrill wrote:
 On 9/3/2014 6:47 AM, Sebastian Huber wrote:
 Hello,

 there are also BSD licensed CMSIS versions:

 http://comments.gmane.org/gmane.comp.lib.libopencm3/361

 The original ARM license makes it pretty useless for us.

 Interestingly, these are from ARM but are really BSD licensed.

 I am not opposed to us using them as long as we review each file
 for appropriate licensing.

 Someone from the RTEMS Community would also need to step up
 and make sure we get updates periodically. Basically help out the
 guy with the github site. Nothing is worse that importing third party
 source without an upstream connection and feedback loop.


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



-- 

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

Re: [PATCH] bsp/tms570: fix get time resolution after infrastructure change to timecounter.

[Daniel Gutson]

On Wed, Jul 15, 2015 at 8:46 AM, Premysl Houdek kom541...@gmail.com wrote:
 Signed-off-by: Premysl Houdek kom541...@gmail.com
 ---
  c/src/lib/libbsp/arm/tms570/clock/clock.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

 diff --git a/c/src/lib/libbsp/arm/tms570/clock/clock.c 
 b/c/src/lib/libbsp/arm/tms570/clock/clock.c
 index 98ee5d9..0770570 100644
 --- a/c/src/lib/libbsp/arm/tms570/clock/clock.c
 +++ b/c/src/lib/libbsp/arm/tms570/clock/clock.c
 @@ -50,12 +50,17 @@ static void 
 tms570_clock_driver_support_initialize_hardware( void )
  {

uint32_t microsec_per_tick = 
 rtems_configuration_get_microseconds_per_tick();
 +  uint32_t tc_frequency = 100;
 +  uint32_t tc_prescaller;

Can't these be const? (Remember http://gamesfromwithin.com/the-const-nazi)


rtems_counter_initialize_converter(BSP_PLL_OUT_CLOCK);

 +  tc_prescaller = (BSP_PLL_OUT_CLOCK + tc_frequency) / (tc_frequency * 2);
 +  tc_frequency = (BSP_PLL_OUT_CLOCK + tc_prescaller) / (tc_prescaller * 2);
 +
/* Hardware specific initialize */
TMS570_RTI.RTIGCTRL = 0;
 -  TMS570_RTI.RTICPUC0 = BSP_PLL_OUT_CLOCK /100 / 2; /* prescaler */
 +  TMS570_RTI.RTICPUC0 = tc_prescaller; /* prescaler */
TMS570_RTI.RTITBCTRL = 2;
TMS570_RTI.RTICAPCTRL = 0;
TMS570_RTI.RTICOMPCTRL = 0;
 @@ -76,7 +81,7 @@ static void 
 tms570_clock_driver_support_initialize_hardware( void )
/* set timecounter */
tms570_rti_tc.tc_get_timecount = tms570_rti_get_timecount;
tms570_rti_tc.tc_counter_mask = 0x;
 -  tms570_rti_tc.tc_frequency = BSP_PLL_OUT_CLOCK;
 +  tms570_rti_tc.tc_frequency = tc_frequency;
tms570_rti_tc.tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
rtems_timecounter_install(tms570_rti_tc);
  }
 --
 1.9.1

 ___
 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

Re: RTEMS for ARM Cortex-M1 ?

[Daniel Gutson]

On Tue, Feb 17, 2015 at 10:53 AM, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:

 El 14/02/2015 10:29, Sebastian Huber sebastian.hu...@embedded-brains.de
 escribió:

 On 14/02/15 14:27, Sebastian Huber wrote:

 On 14/02/15 12:48, Daniel Gutson wrote:

 We're developing support for the
 cortex M 4 so we can let you know once we commit the patches so you can
 have a starting point in case an emulator is also needed.


 The Cortex-M4 is already supported including the FPU (e.g. LPC4088).


 Hm, I should read more carefully.  You added a Cortex-M4 support for Qemu
 including the FPU?

 We are currently working on it, but we're focused in the DSP part of the
 instruction set rather than the FP part.

FWIW, it has been committed: (both patches are required)

http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg03724.html
http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg04234.html


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




-- 

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

Re: USB Host and MMC/SD Card Stack

[Daniel Gutson]

Thanks Sebastian.

We will use it in the BeagleBone Black BSD.

On Tue, Jun 9, 2015 at 4:16 AM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
 Hello Daniel,

 the USB host and MMC/SD card stack is from FreeBSD 9. It works quite well on
 our targets.


 On 05/06/15 18:27, Daniel Gutson wrote:

 Hi Sebastian,

 is this industrial-grade fully functional, or has known issues? If
 it has, we could fix them.

 Thanks,

 Daniel.

 On Mon, May 18, 2015 at 4:01 AM, Sebastian Huber
 sebastian.hu...@embedded-brains.de wrote:

 On 16/05/15 20:53, Afshin Jamaali (Arian) wrote:

 Hi Sebastian,

 Sorry, it seems a problem exists. The link
 http://git.rtems.org/rtems-libbsd.git/; says:
 No repositories found


 Sorry, the right link is:

 https://git.rtems.org/rtems-libbsd

 Best Regards,
 Afshin Jamaali


 -Original Message-
 From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian
 Huber
 Sent: Friday, May 15, 2015 18:25
 To: devel@rtems.org
 Subject: Re: USB Host and MMC/SD Card Stack

 Hello,

 the USB host and MMC/SD card stack for RTEMS is now available via the
 libbsd:

 http://git.rtems.org/rtems-libbsd.git/

 I will remove my libusb repository to avoid confusion.

 On 27/08/14 14:19, Sebastian Huber wrote:

 Hello,

 I added a USB host and MMC/SD card stack for RTEMS (libusb) to my Git
 repository area:

 http://git.rtems.org/sebh/rtems-libusb.git/

 It was previously only available as a snapshot:

 https://www.rtems.org/bugzilla/show_bug.cgi?id=1601

 The USB host stack is a port from FreeBSD 8.  The MMC/SD card stack is
 a port from FreeBSD 9.3.

 The libusb is a subset an older version of the libbsd which contains
 also the network stack from FreeBSD 9.3.  We use libusb on some boards
 and projects.  I simply had no time to test the USB and MMC/SD parts
 in libbsd.

 http://git.rtems.org/rtems-libbsd/

 Both libraries lack documentation.  The basic network stack in libbsd
 works well, but more work is required to polish it.

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


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




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




-- 

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

Re: USB Host and MMC/SD Card Stack

[Daniel Gutson]

Hi Sebastian,

   is this industrial-grade fully functional, or has known issues? If
it has, we could fix them.

Thanks,

   Daniel.

On Mon, May 18, 2015 at 4:01 AM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
 On 16/05/15 20:53, Afshin Jamaali (Arian) wrote:

 Hi Sebastian,

 Sorry, it seems a problem exists. The link
 http://git.rtems.org/rtems-libbsd.git/; says:
 No repositories found


 Sorry, the right link is:

 https://git.rtems.org/rtems-libbsd


 Best Regards,
 Afshin Jamaali


 -Original Message-
 From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber
 Sent: Friday, May 15, 2015 18:25
 To: devel@rtems.org
 Subject: Re: USB Host and MMC/SD Card Stack

 Hello,

 the USB host and MMC/SD card stack for RTEMS is now available via the
 libbsd:

 http://git.rtems.org/rtems-libbsd.git/

 I will remove my libusb repository to avoid confusion.

 On 27/08/14 14:19, Sebastian Huber wrote:

 Hello,

 I added a USB host and MMC/SD card stack for RTEMS (libusb) to my Git
 repository area:

 http://git.rtems.org/sebh/rtems-libusb.git/

 It was previously only available as a snapshot:

 https://www.rtems.org/bugzilla/show_bug.cgi?id=1601

 The USB host stack is a port from FreeBSD 8.  The MMC/SD card stack is
 a port from FreeBSD 9.3.

 The libusb is a subset an older version of the libbsd which contains
 also the network stack from FreeBSD 9.3.  We use libusb on some boards
 and projects.  I simply had no time to test the USB and MMC/SD parts
 in libbsd.

 http://git.rtems.org/rtems-libbsd/

 Both libraries lack documentation.  The basic network stack in libbsd
 works well, but more work is required to polish it.

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


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



-- 

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

Re: [PATCH] Regenerate with FreeBSD lex, yacc, and rpcgen tools.

[Daniel Gutson]

I see things like unsigned long in some changes (specially macro
constants) rather than the stdint.h types. Please point me to the generator
tool location and I will contribute a patch to FreeBSD (meanwhile we could
use them).
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

New patch to create C++ exceptions-free multilib

[Daniel Gutson]

Hi,

   with this (just approved) patch
   https://gcc.gnu.org/ml/libstdc++/2015-04/msg00104.html
the toolchain can be built containing an exceptions-free multilib (if
the -fno-exceptions flag is specified
in the target fragment file).
This means that now the same toolchain can generate binary versions
with and without exceptions.

Do you think this is worth to be added to the RSB?

  Daniel.

-- 

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

Re: qemu fails to build with RSB on CentOS 6

[Daniel Gutson]

ld is really ld or gold?

Version?
El 16/4/2015 18:52, Joel Sherrill joel.sherr...@oarcorp.com escribió:

 Hi

 Has anyone seen this failure?

 $ make
 lt LINK vscclient
 /usr/bin/ld: -f may not be used without -shared
 collect2: ld returned 1 exit status
 make: *** [vscclient] 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

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

Re: Pthreads pretty printers

[Daniel Gutson]

El 29/03/2015 20:52, Chris Johns chr...@rtems.org escribió:

 On 30/03/2015 8:23 am, Daniel Gutson wrote:
 
 We are waiting for the (hopefully) last round of comments for our gdb
  pretty printers of glibc's NPTL.

 Do you have a suitable link ?

https://sourceware.org/ml/libc-alpha/2015-03/msg00833.html


  Is there interest here for an RTEMS version as well?

 Yes. We have support for RTEMS here
 https://git.rtems.org/rtems-tools/tree/tools/gdb/python and posix.py
 support is something I would like to add.

 To load build and install the rtems-tools package. The RSB does this now
 and then in gdb do:

  (gdb) python import rtems

 and for classic API we have:

  (gdb) rtems task

 I have been working to clean up the package and something things in this
 code base are present but need testing, eg the rbtrees.py.

 The posix support would be an Id wrapper for the POSIX class threads and
 then the common thread code would be used to examine the thread. A nice
 feature for posix thread display would mapping the start address to a
 gdb function symbol to help users know which pthread is which.

Thanks. I'll analyze this with my team and be back.

   Daniel.


 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: [PATCH] TMS570: Add board reset code to bsp_reset

[Daniel Gutson]

On Thu, Mar 26, 2015 at 5:16 PM, Martin Galvan
martin.gal...@tallertechnologies.com wrote:
 ---
  c/src/lib/libbsp/arm/tms570/include/tms570.h   | 19 +++--
  c/src/lib/libbsp/arm/tms570/startup/bspreset.c | 37 
 --
  2 files changed, 34 insertions(+), 22 deletions(-)

 diff --git a/c/src/lib/libbsp/arm/tms570/include/tms570.h 
 b/c/src/lib/libbsp/arm/tms570/include/tms570.h
 index 2023a29..50f1315 100644
 --- a/c/src/lib/libbsp/arm/tms570/include/tms570.h
 +++ b/c/src/lib/libbsp/arm/tms570/include/tms570.h
 @@ -7,15 +7,9 @@
   */

  /*
 - * Copyright (c) 2014 Premysl Houdek kom541...@gmail.com
 + * Copyright (c) 2015 Taller Technologies.

Is this correct, or should we both be listed here? Be careful here.

   *
 - * Google Summer of Code 2014 at
 - * Czech Technical University in Prague
 - * Zikova 1903/4
 - * 166 36 Praha 6
 - * Czech Republic
 - *
 - * Based on LPC24xx and LPC1768 BSP
 + * @author Martin Galvan martin.gal...@tallertechnologies.com
   *
   * The license and distribution terms for this file may be
   * found in the file LICENSE in this distribution or at
 @@ -25,4 +19,13 @@
  #ifndef LIBBSP_ARM_TMS570_H
  #define LIBBSP_ARM_TMS570_H

 +#define SYSECR (*(uint32_t *)0xFFE0u) /* System Exception Control 
 Register */
 +#define ESMIOFFHR (*(uint32_t *)0xF528) /* ESM Interrupt Offset High 
 Register */
 +#define ESMSR1 (*(uint32_t *)0xF518u) /* ESM Status Register 1 */
 +#define ESMSR2 (*(uint32_t *)0xF51Cu) /* ESM Status Register 2 */
 +#define ESMSR3 (*(uint32_t *)0xF520u) /* ESM Status Register 3 */
 +#define ESMSR4 (*(uint32_t *)0xF558u) /* ESM Status Register 4 */
 +
 +#define SYSECR_RESET 0x8u
 +
  #endif /* LIBBSP_ARM_TMS570_H */
 diff --git a/c/src/lib/libbsp/arm/tms570/startup/bspreset.c 
 b/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
 index d47920c..a4b6647 100644
 --- a/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
 +++ b/c/src/lib/libbsp/arm/tms570/startup/bspreset.c
 @@ -7,30 +7,39 @@
   */

  /*
 - * Copyright (c) 2014 Premysl Houdek kom541...@gmail.com
 + * Copyright (c) 2015 Taller Technologies.
   *
 - * Google Summer of Code 2014 at
 - * Czech Technical University in Prague
 - * Zikova 1903/4
 - * 166 36 Praha 6
 - * Czech Republic
 - *
 - * Based on LPC24xx and LPC1768 BSP
 + * @author Martin Galvan martin.gal...@tallertechnologies.com
   *
   * The license and distribution terms for this file may be
   * found in the file LICENSE in this distribution or at
   * http://www.rtems.org/license/LICENSE.
   */

 -#include rtems.h
 -
 -#include bsp/bootcard.h
 +#include bsp.h
  #include bsp/tms570.h
  #include bsp/start.h

 -BSP_START_TEXT_SECTION __attribute__( ( flatten ) ) void bsp_reset( void )
 +static void handle_esm_errors(uint32_t esm_irq_channel)
 +{
 +  /* ESMR3 errors don't generate interrupts. */
 +  if (esm_irq_channel  0x20u) {
 +ESMSR1 = 1  esm_irq_channel;
 +  } else if (esm_irq_channel  0x40u) {
 +ESMSR2 = 1  (esm_irq_channel - 32u);
 +  } else if (esm_irq_channel  0x60u) {
 +ESMSR4 = 1  (esm_irq_channel - 64u);
 +  }
 +}
 +
 +void bsp_reset(void)
  {
 -  while ( true ) {
 -/* Do nothing */
 +  uint32_t esm_irq_channel = ESMIOFFHR - 1;
 +
 +  if (esm_irq_channel) {
 +handle_esm_errors(esm_irq_channel);
}
 +
 +  /* Reset the board */
 +  SYSECR = SYSECR_RESET;
  }
 --
 2.3.4

 ___
 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

Re: [PATCH 12/42] libcrypt/crypt-md5.c: Fix overflow issues

[Daniel Gutson]

El 25/03/2015 21:41, Joel Sherrill joel.sherr...@oarcorp.com escribió:



 On March 24, 2015 8:37:57 AM CDT, Daniel Gutson 
daniel.gut...@tallertechnologies.com wrote:
 In order to avoid code duplication and ease future bugfixing, I suggest
 to have a conditional casting and leave the core code alone, something
 like
 
 #ifdef __rtems__
 #define cast(x) ((unsigned long int)x)
 #else
 #define cast(x) (x)
 #endif
 
 ...cast(final[ 0]  16)...
 
 #undef cast

 Good suggestion. The big concern is really just making sure changes made
to the imported code is clear. I suppose this does it as well.

Is this really RTEMS-specific? If it isn't, what about contributing it to
the original code?



 El 23/03/2015 11:52, Joel Sherrill joel.sherr...@oarcorp.com
 escribió:
 
 ---
  cpukit/libcrypt/crypt-md5.c | 12 
  1 file changed, 12 insertions(+)
 
 diff --git a/cpukit/libcrypt/crypt-md5.c b/cpukit/libcrypt/crypt-md5.c
 index c60dcf8..78ae0bc 100644
 --- a/cpukit/libcrypt/crypt-md5.c
 +++ b/cpukit/libcrypt/crypt-md5.c
 @@ -133,6 +133,17 @@ crypt_md5_r(const char *pw, const char *salt,
 struct crypt_data *data)
 
 p = passwd + strlen(passwd);
 
 +#if defined(__rtems__)
 +   l = ((long int) final[ 0]16) | ((long int) final[ 6]8) |
 final[12];
 +   _crypt_to64(p, l, 4); p += 4;
 +   l = ((long int) final[ 1]16) | ((long int) final[ 7]8) |
 final[13];
 +   _crypt_to64(p, l, 4); p += 4;
 +   l = ((long int) final[ 2]16) | ((long int) final[ 8]8) |
 final[14];
 +   _crypt_to64(p, l, 4); p += 4;
 +   l = ((long int) final[ 3]16) | ((long int) final[ 9]8) |
 final[15];
 +   _crypt_to64(p, l, 4); p += 4;
 +   l = ((long int) final[ 4]16) | ((long int) final[10]8) |
 final[ 5];
 +#else
 l = (final[ 0]16) | (final[ 6]8) | final[12];
 _crypt_to64(p, l, 4); p += 4;
 l = (final[ 1]16) | (final[ 7]8) | final[13];
 @@ -142,6 +153,7 @@ crypt_md5_r(const char *pw, const char *salt,
 struct crypt_data *data)
 l = (final[ 3]16) | (final[ 9]8) | final[15];
 _crypt_to64(p, l, 4); p += 4;
 l = (final[ 4]16) | (final[10]8) | final[ 5];
 +#endif
 _crypt_to64(p, l, 4); p += 4;
 l = final[11];
 _crypt_to64(p, l, 2); p += 2;
 --
 1.9.3
 
 ___
 devel mailing list
 devel@rtems.org
 http://lists.rtems.org/mailman/listinfo/devel

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

Re: Pushing all but one patch

[Daniel Gutson]

El 24/03/2015 10:34, Joel Sherrill joel.sherr...@oarcorp.com escribió:



 On 3/24/2015 8:29 AM, Daniel Gutson wrote:


 El 24/03/2015 10:17, Joel Sherrill joel.sherr...@oarcorp.com
escribió:
 
  Hi
 
  I am pushing all but the one patch that was commented on.
  I will try the suggested alternative approach to eliminating
  the warning before pushing some solution.

 I'm just back from a trip and I am not sure what that remaining patch is
or its related warning. Is the one shown in the mail with subject Last
warnings from yesterday? Please point me to it if not since I'd like to
help.

 Gedare had a question if I have picked the right way to address one
warning.

 The last warning is in the sh1 BSP and I think it has something to do
with the
 way it defines its driver macros.

 I am seriously down to the last warnings!! It is a matter of ignoring
some that
 are gcc false positives, knowing a newer gcc doesn't flag some and fixing
 that very painful intptr_t inttypes.h issue.

Thanks, I'll take a look.


 Anyway I'm accessing from a smartphone without access to the source code
until tomorrow.

 I do that myself a lot. Sometimes it isn't a smart thing to do. :)

I have the additional difficulty that I'm answering hiding from my wife
since I'm still technically in my honeymoon until tomorrow :)




 Thanks!

Daniel.

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


 --
 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 12/42] libcrypt/crypt-md5.c: Fix overflow issues

[Daniel Gutson]

In order to avoid code duplication and ease future bugfixing, I suggest to
have a conditional casting and leave the core code alone, something like

#ifdef __rtems__
#define cast(x) ((unsigned long int)x)
#else
#define cast(x) (x)
#endif

...cast(final[ 0]  16)...

#undef cast
El 23/03/2015 11:52, Joel Sherrill joel.sherr...@oarcorp.com escribió:

 ---
  cpukit/libcrypt/crypt-md5.c | 12 
  1 file changed, 12 insertions(+)

 diff --git a/cpukit/libcrypt/crypt-md5.c b/cpukit/libcrypt/crypt-md5.c
 index c60dcf8..78ae0bc 100644
 --- a/cpukit/libcrypt/crypt-md5.c
 +++ b/cpukit/libcrypt/crypt-md5.c
 @@ -133,6 +133,17 @@ crypt_md5_r(const char *pw, const char *salt, struct
 crypt_data *data)

 p = passwd + strlen(passwd);

 +#if defined(__rtems__)
 +   l = ((long int) final[ 0]16) | ((long int) final[ 6]8) |
 final[12];
 +   _crypt_to64(p, l, 4); p += 4;
 +   l = ((long int) final[ 1]16) | ((long int) final[ 7]8) |
 final[13];
 +   _crypt_to64(p, l, 4); p += 4;
 +   l = ((long int) final[ 2]16) | ((long int) final[ 8]8) |
 final[14];
 +   _crypt_to64(p, l, 4); p += 4;
 +   l = ((long int) final[ 3]16) | ((long int) final[ 9]8) |
 final[15];
 +   _crypt_to64(p, l, 4); p += 4;
 +   l = ((long int) final[ 4]16) | ((long int) final[10]8) |
 final[ 5];
 +#else
 l = (final[ 0]16) | (final[ 6]8) | final[12];
 _crypt_to64(p, l, 4); p += 4;
 l = (final[ 1]16) | (final[ 7]8) | final[13];
 @@ -142,6 +153,7 @@ crypt_md5_r(const char *pw, const char *salt, struct
 crypt_data *data)
 l = (final[ 3]16) | (final[ 9]8) | final[15];
 _crypt_to64(p, l, 4); p += 4;
 l = (final[ 4]16) | (final[10]8) | final[ 5];
 +#endif
 _crypt_to64(p, l, 4); p += 4;
 l = final[11];
 _crypt_to64(p, l, 2); p += 2;
 --
 1.9.3

 ___
 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: Pushing all but one patch

[Daniel Gutson]

El 24/03/2015 10:17, Joel Sherrill joel.sherr...@oarcorp.com escribió:

 Hi

 I am pushing all but the one patch that was commented on.
 I will try the suggested alternative approach to eliminating
 the warning before pushing some solution.

I'm just back from a trip and I am not sure what that remaining patch is or
its related warning. Is the one shown in the mail with subject Last
warnings from yesterday? Please point me to it if not since I'd like to
help.
Anyway I'm accessing from a smartphone without access to the source code
until tomorrow.

Thanks!

   Daniel.


 --
 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: lwIP for beaglebone black

[Daniel Gutson]

Marcos, please guide him so he can finish the remaining tasks to get lwip
official support, specially the RSB part.

Thanks,

  Daniel.


On March 13, 2015 6:30:40 PM CDT, Marcos Díaz 
marcos.d...@tallertechnologies.com wrote:
Hi,
Indeed we have it working but we only can use it with the cache
disabled because the system crashes otherway.

This could be an MMU setup issue. A region marked cacheable that shouldn't
be.

About what's next, I think there should be a revision of the code and
debugging in order to make it work with the cache enabled. And also see
the way of submitting it to rtems. It was suggested to upload it in
rtems source builder and try to make it easier to configure

He is looking at this as part of a gsoc project so could help take a work
in progress and push it to completion.


El mar 13, 2015 6:52 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com escribió:

Hi Ragu.

 We're successfully using it in production code. We had no time to
contribute it yet, AFAIK blocked in the source builder. Marcos,
details please?

 Daniel.

On Fri, Mar 13, 2015 at 6:00 PM, ragu nath ragunath3...@gmail.com
wrote:
 Hi,

 I would like to know what is the status of running lwIP on beaglebone
 black on RTEMS.  I understand that  there was some considerable
amount
 of work already done on running lwIP on BBB.  It would be really
 helpful if I can get the details on what has already been done and
 what are the remaining things to be done.


 Thanks,
 Ragunath



--

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

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

Re: RTEMS for ARM Cortex-M1 ?

[Daniel Gutson]

El 13/02/2015 22:59, Cudmore, Alan P. (GSFC-5820) alan.p.cudm...@nasa.gov
escribió:

 A project is looking at using RTEMS on an FPGA based ARM Cortex-M1 like
 the one in the Microsemi ProAsic3L development kit:

http://www.microsemi.com/products/fpga-soc/design-resources/dev-kits/proasi
 c3/cortex-m1-enabled-proasic3l-development-kit

 Wikipedia says the Cortex-M1 is an ARMv6M architecture.
 http://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M1

 I see that there is ARMv7M support in score, would a similar be
 needed for ARMv6M?

 Is an ARMv6M close to anything in RTEMS now?

FWIW, We've developed a BSP for the cortex m3 which AFAIK has a reduced
instruction set so the profiles should be similar. With correct
configuration of the ticker and console drivers, the armv7-m should be a
good starting point for your BSP.
The GNU tool chain already supports the architecture, so all is needed from
that side is the proper linker script. Finally,there's qemu which support
Was not finished last time I checked. We're developing support for the
cortex M 4 so we can let you know once we commit the patches so you can
have a starting point in case an emulator is also needed.

 Thanks,
 Alan

 ___
 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: how patching

[Daniel Gutson]

Just to clarify: the ability to provide a new piece of binary
corresponding to a driver and replace the existing one.
Have anybody tried this before?

Thanks!

   Daniel.

On Fri, Feb 13, 2015 at 12:27 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
 Hi,

is there any current experience / support with hot patching? E.g.
 patching a driver while the whole system is running.

 Thanks,

Daniel.

 --

 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



-- 

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

how patching

[Daniel Gutson]

Hi,

   is there any current experience / support with hot patching? E.g.
patching a driver while the whole system is running.

Thanks,

   Daniel.

-- 

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

Re: [PATCH 1/3] Add rtems_filesystem_make_dev_t_from_pointer()

[Daniel Gutson]

On Wed, Feb 4, 2015 at 1:16 PM, Daniel Gutson 
daniel.gut...@tallertechnologies.com wrote:

 Hi Sebastian,

 On Wed, Feb 4, 2015 at 10:46 AM, Sebastian Huber 
 sebastian.hu...@embedded-brains.de wrote:

 ---
  cpukit/libcsupport/include/rtems/libio.h | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/cpukit/libcsupport/include/rtems/libio.h
 b/cpukit/libcsupport/include/rtems/libio.h
 index a4607de..998cd30 100644
 --- a/cpukit/libcsupport/include/rtems/libio.h
 +++ b/cpukit/libcsupport/include/rtems/libio.h
 @@ -1442,6 +1442,16 @@ static inline dev_t rtems_filesystem_make_dev_t(
return temp.device;
  }

 +static inline dev_t rtems_filesystem_make_dev_t_from_pointer(
 +  const void *pointer
 +)
 +{
 +  uint64_t one = 1;
 +  uint64_t temp = (one  63) | (((uintptr_t) pointer)  1);


 Sorry the irrelevant detail, but may I ask why not

 (((uint64_t)1)  63) ...

 ?

 I know that anyway the variable will likely be optimized out.


FWIW, gcc without optimization flags produces different code (thouth -O2
produces the same).




 +
 +  return rtems_filesystem_make_dev_t((uint32_t) (temp  32), (uint32_t)
 temp);
 +}
 +
  static inline rtems_device_major_number rtems_filesystem_dev_major_t(
dev_t device
  )
 --
 1.8.1.4

 ___
 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




-- 

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

Re: [PATCH 1/3] Add rtems_filesystem_make_dev_t_from_pointer()

[Daniel Gutson]

On Wed, Feb 4, 2015 at 1:27 PM, Gedare Bloom ged...@gwu.edu wrote:

 On Wed, Feb 4, 2015 at 11:16 AM, Daniel Gutson
 daniel.gut...@tallertechnologies.com wrote:
  Hi Sebastian,
 
  On Wed, Feb 4, 2015 at 10:46 AM, Sebastian Huber
  sebastian.hu...@embedded-brains.de wrote:
 
  ---
   cpukit/libcsupport/include/rtems/libio.h | 10 ++
   1 file changed, 10 insertions(+)
 
  diff --git a/cpukit/libcsupport/include/rtems/libio.h
  b/cpukit/libcsupport/include/rtems/libio.h
  index a4607de..998cd30 100644
  --- a/cpukit/libcsupport/include/rtems/libio.h
  +++ b/cpukit/libcsupport/include/rtems/libio.h
  @@ -1442,6 +1442,16 @@ static inline dev_t rtems_filesystem_make_dev_t(
 return temp.device;
   }
 
  +static inline dev_t rtems_filesystem_make_dev_t_from_pointer(
  +  const void *pointer
  +)
  +{
  +  uint64_t one = 1;
  +  uint64_t temp = (one  63) | (((uintptr_t) pointer)  1);
 
 
  Sorry the irrelevant detail, but may I ask why not
 
  (((uint64_t)1)  63) ...
 
  ?
 
 Or (1UL  63)

It could be 1ULL, but AFAIK it is platform-dependent, so I preferred
the explicit cast.


  I know that anyway the variable will likely be optimized out.
 
 
  +
  +  return rtems_filesystem_make_dev_t((uint32_t) (temp  32), (uint32_t)
  temp);
  +}
  +
   static inline rtems_device_major_number rtems_filesystem_dev_major_t(
 dev_t device
   )
  --
  1.8.1.4
 
  ___
  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




-- 

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

watchdog question

[Daniel Gutson]

Hi,

   We are thinking about a supervisor watchdog, which runs in a high
priority task, and
has the following characteristics:

a) tasks that want to be supervised are registered in the supervisor watchdog
b) each supervised task is in one of the following mode:
   - automatic supervision
   - manual supervision
   - sleeping
c) in automatic supervision mode, the supervisor watchdog keeps
track of the program counter of the task.
When the PC is the same after N cycles, the watchdog performs a
predefined action (e.g. reset).
d) supervised tasks in manual supervision have to kick the watchdog
explicitly (e.g. by invoking a function of the API).
e) the watchdog leaves alone the tasks in sleeping mode.

The idea of the automatic supervision mode is to avoid polluting the
task code due to spreading calls to the kick function,
specially difficult when having to estimate the distance between
these function calls.
The idea of the manual supervision mode, which is rather
traditional, is when the task executes tight inner loops.
In this scheme, tasks should be in automatic mode as much as possible
and switch to manual just in small bounded
places of the code.

Before entering in the discussion of the implementation, I'd like
feeedback about the general idea please.

Thanks!

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

Re: Fwd: Sebastian Huber appointed RTEMS Co-Maintainer

[Daniel Gutson]

Congratulations!

--Mensaje original--
De: Joel Sherrill
Remitente: devel
Para: us...@rtems.org
Para: devel@rtems.org
Asunto: Fwd: Sebastian Huber appointed RTEMS Co-Maintainer
Enviado: 21 de dic de 2014 2:13 PM



 Original Message 
Subject:Sebastian Huber appointed RTEMS Co-Maintainer
Date:   Sun, 21 Dec 2014 10:46:40 -0600
From:   Joel Sherrill joel.sherr...@oarcorp.com
To: g...@gcc.gnu.org g...@gcc.gnu.org, 
sebastian.hu...@embedded-brains.de sebastian.hu...@embedded-brains.de



Hi

I am pleased to announce that the steering committee
has appointed Sebastian Huber as co-maintainer of
the RTEMS target in GCC.

This is a reflection of the work has done and community
involvement Sebastian has already had. We are looking
forward to more of this in the future.

Please adjust the MAINTAINERS file accordingly, and Happy Hacking!

-- Joel Sherrill, Ph.D. Director of Research  Development
joel.sherr...@oarcorp.com On-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

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

Re: Reducing RTEMS size to 32KB to fit in Epiphany local memories

[Daniel Gutson]

Maybe it's worth to mention the 20k or so EH-related buffers?
I think they go away when building the STL without EH and RTTI support,
right?

On Wed, Dec 17, 2014 at 2:44 PM, Marcos Díaz 
marcos.d...@tallertechnologies.com wrote:

 That particular test I could see it uses like four tasks. The problem we
 had in the past is that the predefined size for the stack for each task was
 set to 4k for our architecture (arm cortex m3). We proposed a patch in
 order to make the default stack size for each bsp configurable. Im not sure
 if it has been submitted

 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER

 #define CONFIGURE_MAXIMUM_TASKS 4

 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE

 #define CONFIGURE_EXTRA_TASK_STACKS (3 * RTEMS_MINIMUM_STACK_SIZE)

 #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION

 this is extracted from the system.h file of ticker test.

 If your objective is to have that test working, i suggest to tune the
 minimum stack size in this file.
 If you want to know a little more, I suggest that you make a objdump and
 see what global objects are using more RAM and where did they come from.

 On Wed, Dec 17, 2014 at 1:36 PM, Daniel Gutson 
 daniel.gut...@tallertechnologies.com wrote:

 We were able to downsize RTEMS to about 9k for the LPC1768.
 Marcos, could you give a hint?

 On Wed, Dec 17, 2014 at 1:34 PM, Joel Sherrill joel.sherr...@oarcorp.com
  wrote:



 On December 17, 2014 8:00:50 AM PST, Hesham Moustafa 
 heshamelmat...@gmail.com wrote:
 Hi all,
 
 I am working on reducing RTEMS size to fit into 32KB as every Epiphay
 core has only 32KB of local memory. I was able to get hello and
 minimum samples with aggressive size reduction by manually removing
 un-needed code. Currently I only use libcsupport, sapi, score, rtems
 built for cpukit only, and for each, some source code files were
 removed. No IO, no FS, no barrier, event, managers are included.

 Our minimum is where it is because no one has provided lower
 requirements. Some of the things you dropped out could be addressed by
 initialization being more like a constructor table that is automatically
 built based on dependencies. This was/is the sequenced initialization
 project. I don't know the state of it.

 Try turning on per section methods and data like the SPARC bsps. This
 saves memory.


 Defining which features are part of 'nanoRTEMS' is a big part of this.
 Then those requirements can drive dropping things not covered by sequenced
 initialization and finer tuning.

 Using printk saves a lot of memory.

 And I
 added -Os flag. However when building ticker, the .text area overflows
 the 32KB local memory by about 8KB.
 
 The question is, what are the very basic mandatory sources/libraries
 and/or managers that are enough to build ticker?

 Some of that is stack size in ticker. Look at the ticker variants in
 examples-v2

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

 --joel
 ___
 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



 --

 __

 http://www.tallertechnologies.com


 Marcos Díaz

 Software Engineer


 San Lorenzo 47, 3rd Floor, Office 5

 Córdoba, Argentina


 Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452

 Skype: markdiaz22



-- 

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

Re: Updating Open Projects and GSOC

[Daniel Gutson]

FWIW, we have a fully functional LWIP eth stack for the Beaglebone Black that 
we'll contribute soon.

Maybe exploring/prototyping some dynamic checkers (specially for concurrency) 
would be an option for gsoc.
--Mensaje original--
De: Joel Sherrill
Remitente: devel
Para: us...@rtems.org
Para: devel@rtems.org
Asunto: Updating Open Projects and GSOC
Enviado: 13 de dic de 2014 12:58 PM

Hi

Google Summer of Code 2014 has wrapped up and the 2015
edition is already committed to by Google. I would
like folks to take a little while to update pages
and add any new ideas. A few off my wish list in no
particular order:

+ More Pi peripherals
   - includes TCP/IP over USB
+ BeagleBoard Ethernet
+ rtems-tester support for more simulators
+ complete rtems-tester coverage support
   - started in ESA SOCIS
+ more RSB recipes
   - specifically eliminate RTEMS Addon Packages
 and as much of the Graphics Toolkit as possible
 with RSB recipes
+ Monkey HTTPD port
+ capture engine, trace wrapper generator, and
   LTTng integration via CTF. Allows visualization
   of timelines
+ Coverity runs on newlib. I started this but can't
   get it to work so far. :(

I am sure there are other ideas. Please add to the
list and help write them up.

--joel
___
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: Question regarding ns16550

[Daniel Gutson]

On Fri, Oct 24, 2014 at 2:16 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
 On Fri, Oct 24, 2014 at 2:33 AM, Sebastian Huber
 sebastian.hu...@embedded-brains.de wrote:
 On 23/10/14 18:12, Daniel Gutson wrote:

 On Thu, Oct 23, 2014 at 5:47 AM, Sebastian Huber
 sebastian.hu...@embedded-brains.de  wrote:

 Hello Daniel,

 Hi Sebastian,

 
 I never notice a problem with this driver.  It should only write to the
  FIFO
 in case it is completely empty.  Did you observe problems?

 no, I didn't (actually I found this while looking for a serial bug
 which turned out to be due
 to a different cause).
 However, I notice that this isn't like what the polling write does (of
 course I'm not talking
 about the polling/interrput difference, but when writing byte-per-byte
 to the FIFO, I think
 both methods should do the same).
 IOW, what happens if the 'for' loop is too fast for the device? Will
 the latter be able to
 put the char in the FIFO and be ready for the next one? Isn't
 SP_LSR_THOLD exactly
 to tell whether the device' FIFO is ready to accept the next byte?
 Writing to the FIFO when it's completely empty is not the problem I
 see since it is
 guaranteed by the interrupt. My concern is different: it's whether the
 FIFO is filled too fast
 for the device.



 Its not clear to me from the documentation if this is really necessary.  I
 never noticed problems on several targets with this driver.

FWIW, we asked TI about this:
http://e2e.ti.com/support/arm/sitara_arm/f/791/p/378177/1331822.aspx#1331822
In short: they explained that the register is not needed when in FIFO
mode, which is the case (but it is needed when writing byte-per-byte).

   Daniel.


 Ok.



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



 --

 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



-- 

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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question regarding ns16550

[Daniel Gutson]

On Fri, Oct 24, 2014 at 2:33 AM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
 On 23/10/14 18:12, Daniel Gutson wrote:

 On Thu, Oct 23, 2014 at 5:47 AM, Sebastian Huber
 sebastian.hu...@embedded-brains.de  wrote:

 Hello Daniel,

 Hi Sebastian,

 
 I never notice a problem with this driver.  It should only write to the
  FIFO
 in case it is completely empty.  Did you observe problems?

 no, I didn't (actually I found this while looking for a serial bug
 which turned out to be due
 to a different cause).
 However, I notice that this isn't like what the polling write does (of
 course I'm not talking
 about the polling/interrput difference, but when writing byte-per-byte
 to the FIFO, I think
 both methods should do the same).
 IOW, what happens if the 'for' loop is too fast for the device? Will
 the latter be able to
 put the char in the FIFO and be ready for the next one? Isn't
 SP_LSR_THOLD exactly
 to tell whether the device' FIFO is ready to accept the next byte?
 Writing to the FIFO when it's completely empty is not the problem I
 see since it is
 guaranteed by the interrupt. My concern is different: it's whether the
 FIFO is filled too fast
 for the device.



 Its not clear to me from the documentation if this is really necessary.  I
 never noticed problems on several targets with this driver.

Ok.



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



-- 

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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question regarding ns16550

[Daniel Gutson]

On Thu, Oct 23, 2014 at 5:47 AM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
 Hello Daniel,

Hi Sebastian,


 I never notice a problem with this driver.  It should only write to the FIFO
 in case it is completely empty.  Did you observe problems?

no, I didn't (actually I found this while looking for a serial bug
which turned out to be due
to a different cause).
However, I notice that this isn't like what the polling write does (of
course I'm not talking
about the polling/interrput difference, but when writing byte-per-byte
to the FIFO, I think
both methods should do the same).
IOW, what happens if the 'for' loop is too fast for the device? Will
the latter be able to
put the char in the FIFO and be ready for the next one? Isn't
SP_LSR_THOLD exactly
to tell whether the device' FIFO is ready to accept the next byte?
Writing to the FIFO when it's completely empty is not the problem I
see since it is
guaranteed by the interrupt. My concern is different: it's whether the
FIFO is filled too fast
for the device.



 On 21/10/14 19:32, Daniel Gutson wrote:

 Hi,

 in the writing interrupt mode (ns16550_write_support_int), we have

for (i = 0; i  out; ++i) {
  set( port, NS16550_TRANSMIT_BUFFER, buf [i]);
}

 Shouldn't we check, before writing to the register for the iterations
 after the first one,
 whether the character entered in the FIFO? (otherwise I think the
 'for' loop could iterate
 so fast that the device had no time to process the character)

 In such a case, something like


for (i = 0; i  out; ++i) {

 /* Wait for transmitter holding register to be empty */
  do {
status = get( port, NS16550_LINE_STATUS);
  } while ((status  SP_LSR_THOLD) == 0);

  set( port, NS16550_TRANSMIT_BUFFER, buf [i]);
}

 would be better?

 Thanks,

 Daniel.




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



-- 

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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: dynamic checking tools

[Daniel Gutson]

On Wed, Sep 17, 2014 at 10:45 PM, Mohammed Saeed Khoory
mohammed.kho...@eiast.ae wrote:
 I'm not sure about tools similar to valgrind, but you might find it useful to 
 enable deep memory tests in RTEMS. You can find more information here.
 http://www.rtems.org/wiki/index.php/Debugging#Optional_Compile-time_Selections


Thanks Mohammed, we're already using the heavy stack check; I'll see
what can be done in terms of concurrency checking (specially race
conditions). I'll check Chris' mail.

  Daniel.

 By enabling these macros you can check if your memory is getting corrupted 
 everytime a system call occurs. This is very useful in debugging and has 
 saved me a lot of headaches personally. You can detect stack and heap 
 corruption with these macros.

 I don't think it would detect memory leaks however.

 Hope this helps

 -Original Message-
 From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Daniel Gutson
 Sent: Thursday, September 18, 2014 3:02 AM
 To: RTEMS
 Subject: dynamic checking tools

 Hi guys,

are there any dynamic checking tools (a la
 valgrind/helgrind/memcheck/drd and *sanitizer) for RTEMS?
 More specifically, I'm interested in memory and concurrency checking, more
 specifically for ARM.

 Thanks!

Daniel.

 --

 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
 ___
 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Single Warning Analysis Request

[Daniel Gutson]

Marcos and I will take a look.

On Wed, Sep 17, 2014 at 12:19 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
 Hi

 I would really appreciate it if someone could look into this
 warning and see if we can get an explanation. It could be
 a source code issue or something higher in the tools.
 It is reported on 120 BSP build configurations:

 ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/hexdump-conv.c:145:4:
 warning: format '%lc' expects argument of type 'wint_t', but argument 4
 has type 'wchar_t' [-Wformat=]
 ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/hexdump-conv.c:145:4:
 warning: format '%lc' expects argument of type 'wint_t', but argument 4
 has type 'wchar_t' [-Wformat=]

 Thanks.

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



-- 

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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

dynamic checking tools

[Daniel Gutson]

Hi guys,

   are there any dynamic checking tools (a la
valgrind/helgrind/memcheck/drd and *sanitizer) for RTEMS?
More specifically, I'm interested in memory and concurrency checking,
more specifically for ARM.

Thanks!

   Daniel.

-- 

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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CMSIS?

[Daniel Gutson]

 OR
 CHANGES IN THE ARM DELIVERABLES AT ANY TIME.

 5. LIMITATION OF LIABILITY.

 THE MAXIMUM LIABILITY OF ARM TO YOU IN AGGREGATE FOR ALL CLAIMS MADE
 AGAINST ARM IN CONTRACT, TORT OR OTHERWISE UNDER OR IN CONNECTION WITH
 THE SUBJECT MATTER OF THIS LICENCE SHALL NOT EXCEED THE GREATER OF (I)
 THE TOTAL OF SUMS PAID BY YOU TO ARM (IF ANY) FOR THIS LICENCE AND (II)
 US$10.00. THE LIMITATIONS, EXCLUSIONS AND DISCLAIMERS IN THIS LICENCE
 SHALL APPLY TO THE MAXIMUM EXTENT ALLOWED BY APPLICABLE LAW.

 6. U.S. GOVERNMENT END USERS.

 US Government Restrictions: Use, duplication, reproduction, release,
 modification, disclosure or transfer of this commercial product and
 accompanying documentation is restricted in accordance with the terms of
 this Licence.

 7. TERM AND TERMINATION.

 7.1 This Licence shall remain in force until terminated in accordance
 with the terms of Clause 7.2 or Clause 7.3 below.

 7.2 Without prejudice to any of its other rights if you are in breach of
 any of the terms and conditions of this Licence then ARM may terminate
 this Licence immediately upon giving written notice to you. You may
 terminate this Licence at any time.

 7.3 This Licence shall immediately terminate and shall be unavailable to
 you if you or any party affiliated to you asserts any patents against
 ARM, ARM affiliates, third parties who have a valid licence from ARM for
 the ARM Deliverables, or any customers or distributors of any of them
 based upon a claim that your (or your affiliate) patent is Necessary to
 implement the CMSIS Specification or DSP Library Specification. In this
 Licence; (i) affiliate means any entity controlling, controlled by or
 under common control with a party (in fact or in law, via voting
 securities, management control or otherwise) and affiliated shall be
 construed accordingly; (ii) assert means to allege infringement in
 legal or administrative proceedings, or proceedings before any other
 competent trade, arbitral or international authority; (iii) Necessary
 means with respect to any claims of any patent, those claims which,
 without the appropriate permission of the patent owner, will be
 infringed when implementing the CMSIS Specification or DSP Library
 Specification because no alternative, commercially reasonable,
 non-infringing way of implementing the CMSIS Specification or DSP
 Library Specification is known.

 7.4 Upon termination of this Licence, you shall stop using the ARM
 Deliverables and destroy all copies of the ARM Deliverables in your
 possession. The provisions of clauses 5, 6, 7, and 8 shall survive
 termination of this Licence.

 8. GENERAL.

 This Licence is governed by English Law. Except where ARM agrees
 otherwise in a written contract signed by you and ARM, this is the only
 agreement between you and ARM relating to the ARM Deliverables and it
 may only be modified by written agreement between you and ARM. Except as
 expressly agreed in writing, this Licence may not be modified by
 purchase orders, advertising or other representation by any person. If
 any clause or sentence in this Licence is held by a court of law to be
 illegal or unenforceable the remaining provisions of this Licence shall
 not be affected thereby. The failure by ARM to enforce any of the
 provisions of this Licence, unless waived in writing, shall not
 constitute a waiver of ARM's rights to enforce such provision or any
 other provision of this Licence in the future. This Licence may not be
 assigned without the prior written consent of ARM.

 ARM contract reference LEC-PRE-00489



 
 On 8/29/2014 11:52 PM, Chris Nott wrote:
 Absent answer means no.

 I had the same idea. Actually I have played around with using vendor
 libraries from TI and ST, and there is no problem compiling them in. I
 can't see any reason CMSIS wouldn't fit in fine too. Actually from
 memory the useful parts of CMSIS comprise two parts, ARM specific
 intrinsic instructions and register locations in a header file, and
 reasonable math libraries. It shouldn't be a bit deal to use these, I
 would ignore the CMSIS linker scripts and such though.

 I would like to see CMSIS and parts of the vendor libraries integrated
 with RTEMS if possible, but I am uncertain about licensing
 compatibility. It seems daft to have to rewrite register locations and
 platform specific instructions if the vendors provide them..

 Regards,
 Chris.


 On 29/08/2014 10:04 AM, Daniel Gutson wrote:
 absent answer means NO?

 Thanks,

  Daniel.

 On Thu, Aug 28, 2014 at 11:31 AM, Daniel Gutson
 daniel.gut...@tallertechnologies.com wrote:
 Hi,

 is there any precedent regarding a CMSIS abstraction layer
 implementation on RTEMS?

 Thanks,

 Daniel.

 --

 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

 ___
 devel

Re: CMSIS?

[Daniel Gutson]

absent answer means NO?

Thanks,

Daniel.

On Thu, Aug 28, 2014 at 11:31 AM, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
 Hi,

is there any precedent regarding a CMSIS abstraction layer
 implementation on RTEMS?

 Thanks,

Daniel.

 --

 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



-- 

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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] BSP for TMS570LS31x Hercules Development Kit from TI (TMS570LS3137)

[Daniel Gutson]

On Wed, Aug 13, 2014 at 4:48 PM, Premysl Houdek kom541...@gmail.com wrote:
 Included variants:
   tms570ls3137_hdk_intram - place code and data into internal SRAM
   tms570ls3137_hdk_sdram - place code into external SDRAM and data to SRAM
   tms570ls3137_hdk - variant prepared for stand-alone RTEMS aplication
   stored and running directly from flash. Not working yet.

 Chip initialization code not included in BSP.
 External startup generated by TI's HalCoGen was usedfor
 testing and debugging.

 More information about TMS570 BSP can be found at
   http://www.rtems.org/wiki/index.php/Tms570
 ---
  c/src/lib/libbsp/arm/tms570/Makefile.am|  148 ++
  c/src/lib/libbsp/arm/tms570/README |   64 +++
  c/src/lib/libbsp/arm/tms570/bsp_specs  |   13 +
  c/src/lib/libbsp/arm/tms570/clock/tms570-rti.c |  205 
  c/src/lib/libbsp/arm/tms570/configure.ac   |   45 ++
  .../lib/libbsp/arm/tms570/console/printk-support.c |   68 +++
  c/src/lib/libbsp/arm/tms570/console/tms570-sci.c   |  546 
 
  c/src/lib/libbsp/arm/tms570/include/bsp.h  |  101 
  c/src/lib/libbsp/arm/tms570/include/irq.h  |  134 +
  c/src/lib/libbsp/arm/tms570/include/tms570-pom.h   |  101 
  c/src/lib/libbsp/arm/tms570/include/tms570-rti.h   |   95 
  .../libbsp/arm/tms570/include/tms570-sci-driver.h  |   39 ++
  c/src/lib/libbsp/arm/tms570/include/tms570-sci.h   |   75 +++
  c/src/lib/libbsp/arm/tms570/include/tms570-vim.h   |   74 +++
  c/src/lib/libbsp/arm/tms570/include/tms570.h   |   29 ++
  c/src/lib/libbsp/arm/tms570/irq/irq.c  |  182 +++
  .../make/custom/tms570ls3137_hdk-testsuite.tcfg|   19 +
  .../arm/tms570/make/custom/tms570ls3137_hdk.cfg|   19 +
  .../tms570/make/custom/tms570ls3137_hdk_intram.cfg |   20 +
  .../tms570/make/custom/tms570ls3137_hdk_sdram.cfg  |   19 +
  c/src/lib/libbsp/arm/tms570/pom/tms570-pom.c   |  100 
  c/src/lib/libbsp/arm/tms570/startup/bspreset.c |   37 ++
  c/src/lib/libbsp/arm/tms570/startup/bspstart.c |   46 ++
  .../lib/libbsp/arm/tms570/startup/bspstarthooks.c  |   42 ++
  .../arm/tms570/startup/linkcmds.tms570ls3137_hdk   |   27 +
  .../startup/linkcmds.tms570ls3137_hdk_intram   |   28 +
  .../tms570/startup/linkcmds.tms570ls3137_hdk_sdram |   27 +
  27 files changed, 2303 insertions(+)
  create mode 100644 c/src/lib/libbsp/arm/tms570/Makefile.am
  create mode 100644 c/src/lib/libbsp/arm/tms570/README
  create mode 100644 c/src/lib/libbsp/arm/tms570/bsp_specs
  create mode 100644 c/src/lib/libbsp/arm/tms570/clock/tms570-rti.c
  create mode 100644 c/src/lib/libbsp/arm/tms570/configure.ac
  create mode 100644 c/src/lib/libbsp/arm/tms570/console/printk-support.c
  create mode 100644 c/src/lib/libbsp/arm/tms570/console/tms570-sci.c
  create mode 100644 c/src/lib/libbsp/arm/tms570/include/bsp.h
  create mode 100644 c/src/lib/libbsp/arm/tms570/include/irq.h
  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-pom.h
  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-rti.h
  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-sci-driver.h
  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-sci.h
  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570-vim.h
  create mode 100644 c/src/lib/libbsp/arm/tms570/include/tms570.h
  create mode 100644 c/src/lib/libbsp/arm/tms570/irq/irq.c
  create mode 100644 
 c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk-testsuite.tcfg
  create mode 100644 
 c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg
  create mode 100644 
 c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_intram.cfg
  create mode 100644 
 c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_sdram.cfg
  create mode 100644 c/src/lib/libbsp/arm/tms570/network/tms570-ethernet.c
  create mode 100644 c/src/lib/libbsp/arm/tms570/network/tms570-ethernet.h
  create mode 100644 c/src/lib/libbsp/arm/tms570/pom/tms570-pom.c
  create mode 100644 c/src/lib/libbsp/arm/tms570/startup/bspreset.c
  create mode 100644 c/src/lib/libbsp/arm/tms570/startup/bspstart.c
  create mode 100644 c/src/lib/libbsp/arm/tms570/startup/bspstarthooks.c
  create mode 100644 
 c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk
  create mode 100644 
 c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk_intram
  create mode 100644 
 c/src/lib/libbsp/arm/tms570/startup/linkcmds.tms570ls3137_hdk_sdram

 diff --git a/c/src/lib/libbsp/arm/tms570/Makefile.am 
 b/c/src/lib/libbsp/arm/tms570/Makefile.am
 new file mode 100644
 index 000..6ded6af
 --- /dev/null
 +++ b/c/src/lib/libbsp/arm/tms570/Makefile.am
 @@ -0,0 +1,148 @@
 +##
 +#
 +# @file makefile.am
 +#
 +# @brief Makefile of LibBSP for the TMS570 boards.
 +#
 +
 +ACLOCAL_AMFLAGS = -I ../../../../aclocal
 +
 +include $(top_srcdir)/../../../../automake/compile.am
 +
 +include_bspdir = $(includedir)/bsp
 +
 

Re: KICS! brainstorming

[Daniel Gutson]

Thanks Joel,

  I will let you know once I address all your suggestions.

 Daniel.

On Wed, Jul 23, 2014 at 10:28 AM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:

 On 7/22/2014 1:05 PM, Daniel Gutson wrote:
 Hi,

we are working in a very RAM constrained board, and noticed that
 some symbols could be moved to ROM by declaring them const.

 I have a slight idea about creating a consts-candidate detector tool
 KICS! (Keep It Const, St.! :) ), and wanted to hear some other
 people ideas.

 Initial thoughts:
   - one approach could be a gdb script, in which we first read all the
 RAM memory of global objects after initialization (#1), and compare
 the memory at the end (#2), see what remained unchanged; this could
 throw many false positives but would be a starting point.

   - another, I think tougher, is some pointer-tracking static analysis
 as a gcc plugin (not sure if it is even possible).

 Other ideas?
 A couple other idea without knowing the BSP.

 Turn on per function/data items sections. This has been done for the
 SPARC BSPs
 and had a pretty big impact on the size of the tests. I haven't heard
 any reports
 on real applications yet. This will require changing gcc and linking
 flags and tinkering
 with the linker script if it doesn't use * in all the right places for
 pattern matching.

 Put together a minimal version of your app. Basically just make the
 calls you know
 you need. Don't worry if it runs. Look through the symbol table and see
 if there
 are unexpected or undesired capabilities.  For example, some BSPs
 unintentionally
 put the printk() support in the same file with the real console driver.
 Without
 per-function sections, something calls printk() and end up with the
 console driver
 and termios.

 If your application has lower requirements than what we think of as a
 minimum,
 we can refine our definition of minimum capabilities.

 All of these are important to us as a project. Knowing unexpected
 dependencies,
 turning on per item sections, and lowering minimum capabilities based on
 user
 feedbac.


 (#1) after bsp_start? after rtems_initialize_data_structures?

 (#2) for some user-definition of end, and/or after
 rtems_shutdown_executive or alike?

 Thanks!

Daniel.


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




-- 

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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

KICS! brainstorming

[Daniel Gutson]

Hi,

   we are working in a very RAM constrained board, and noticed that
some symbols could be moved to ROM by declaring them const.

I have a slight idea about creating a consts-candidate detector tool
KICS! (Keep It Const, St.! :) ), and wanted to hear some other
people ideas.

Initial thoughts:
  - one approach could be a gdb script, in which we first read all the
RAM memory of global objects after initialization (#1), and compare
the memory at the end (#2), see what remained unchanged; this could
throw many false positives but would be a starting point.

  - another, I think tougher, is some pointer-tracking static analysis
as a gcc plugin (not sure if it is even possible).

Other ideas?



(#1) after bsp_start? after rtems_initialize_data_structures?

(#2) for some user-definition of end, and/or after
rtems_shutdown_executive or alike?

Thanks!

   Daniel.

-- 

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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [NEW BSP] Mbed lpc1768 board

[Daniel Gutson]

Hi Sebastian,

On Thu, Jun 5, 2014 at 10:49 AM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
 On 2014-06-05 15:20, Marcos Díaz wrote:

 At first we started developing this bsp inside that folder. Although
 it has many similarities with the lpc1778, it has other differences:
 There isn't an external memory controller for our bsp.
 The pinselect is very different for our board (it has more
 similarities with the one for the lpc24xx). Also the GPIO
 The start configuration for the main clock and the pll is quite
 different. And other things

 The macros used for the differentiation of those boards referred to
 the CPU architecture (ARM_MULTILIB_ARCH_V4 ARM_MULTILIB_ARCH_V7M) and
 in some cases we could use the functions for the lpc 24xx,in others
 for the lpc1778, and in others new code.


 We had this problem also on the Freescale MPC5500 and MPC5600 chips.  This
 ARM_MULTILIB_ARCH_V4 and ARM_MULTILIB_ARCH_V7M could be replaced with
 something else.  For example

 http://git.rtems.org/rtems/tree/c/src/lib/libbsp/powerpc/mpc55xxevb/configure.ac

 http://git.rtems.org/rtems/tree/c/src/lib/libcpu/powerpc/mpc55xx/include/regs.h

 We created a macro for our
 bsp, but we should have changed many other macros already placed. Our
 Idea was to not break any existing code, since we can't test for the
 other boards.
 Is it still preferred to merge this new bsp with others?


 I think there is a considerable amount of copy and paste involved here, but
 I didn't review it very closely.

We are aware of the copy-paste and agree that it is excessive, but also
think that the best solution would involve a refactor in the other 2 BSPs
to re-arrange common code of the three BSPs so it can be reused.
Since this is our first contribution, and we did need this BSP working,
we thought that it was better to do this in a two stages asking for
agreement: first, a self-contained BSP in the form we are submitting it now,
and a second stage, discussions in the middle, of refactor involving the
three BSPs.

Would you agree under these terms? We need to keep working in this BSP
by adding more drivers; we are more than willing to do the refactor of the three
BSPs as part of our development.

 So in case you think it is infeasible to
 integrate this BSP into standard the LPC2400 and LPC1700 directory, then we
 can add your specialized BSP.  My feeling is that this will generate more
 work in the long run though.

Agree, please see above.

Thanks Sebastian!

Daniel.


 --
 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.
 ___
 rtems-devel mailing list
 rtems-devel@rtems.org
 http://www.rtems.org/mailman/listinfo/rtems-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

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