Re: Add chapter for newib build in RTEMS Docs

2019-09-12 Thread Sebastian Huber 

On 13/09/2019 03:34, Chris Johns wrote:

On 13/9/19 8:42 am, Joel Sherrill wrote:

On Thu, Sep 12, 2019 at 2:09 PM Gedare Bloom  wrote:

Hello Vaibhav,

It would be nice to provide such documentation, but I don't know that
we have an existing location that would be an ideal fit. I think the
topic is out of scope for User Manual. If you are motivated to write
something though, you could prepare it first as a standalone guide.

If we have a name for the document like "Maintainers Guide" or something,
it could have a focus on procedures that only core developers would need.

+ bootstrapping newlib and building it independently
+ modifying gcc, running tests,
+ submitting Coverity runs
+ running Doxygen
+ ...

These are all valid and important however can these reside in the Software
Engineering manual?

We current have ...

  1. RTEMS Software Engineering
  2. RTEMS Filesystem Design Guide
  3. RTEMS Development Environment Guide
  4. RTEMS BSP and Driver Guide

plus 'RTEMS BSP and Driver Guide' which I am not sure about. All these cover
some aspect of maintaining and developing RTEMS. Should we be considering
consolidation rather than expansion?


Yes, we should definitely aim to consolidate the documentation set and 
not add new documents. I would put this topic into the RTEMS Software 
Engineering.


--
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 v2] Correct initial POSIX signals mask

2019-09-12 Thread Sebastian Huber 

On 12/09/2019 16:41, Joel Sherrill wrote:

+ Modify POSIX thread create extension to ensure expected
  initial signal mask is provided to system threads, initial
  tasks and threads, and inheritied by tasks and threads.
+ Adds psxsignal07 to verify functionality when using a POSIX
  Initialization thread and POSIX threads.
+ Adds psxsignal08 to verify functionality when using a Classic API
  Initialization task and Classic API tasks.

Closes #3794.


Looks good.

--
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] update rtems_waf

2019-09-12 Thread Chris Johns 
On 11/9/19 6:14 pm, Vijay Kumar Banerjee wrote:
> ping :)

Sorry about the delay. OK to push.

Chris

> 
> 
> On Tue, Sep 3, 2019 at 7:04 PM Vijay Kumar Banerjee  > wrote:
> 
> ---
>  file_io/crc/wscript            | 6 +++---
>  filesystem/fat_ramdisk/wscript | 6 +++---
>  rtems_waf                      | 2 +-
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/file_io/crc/wscript b/file_io/crc/wscript
> index f7b0f5b..531da20 100644
> --- a/file_io/crc/wscript
> +++ b/file_io/crc/wscript
> @@ -26,9 +26,9 @@ def build(bld):
>      #
>      # Package the root file system as a C file.
>      #
> -    rootfs.build(bld,
> -                 name = 'fs-root',
> -                 root = 'rootfs')
> +    rootfs.build_from_src_root(bld,
> +                               name = 'fs-root',
> +                               root = 'rootfs')
> 
>      bld(features = 'c cprogram',
>          target = 'crc.exe',
> diff --git a/filesystem/fat_ramdisk/wscript 
> b/filesystem/fat_ramdisk/wscript
> index de806c1..a980187 100644
> --- a/filesystem/fat_ramdisk/wscript
> +++ b/filesystem/fat_ramdisk/wscript
> @@ -26,9 +26,9 @@ def build(bld):
>      #
>      # Package the root file system as a C file.
>      #
> -    rootfs.build(bld,
> -                 name = 'fs-root',
> -                 root = 'rootfs')
> +    rootfs.build_from_src_root(bld,
> +                               name = 'fs-root',
> +                               root = 'rootfs')
> 
>      bld(features = 'c cprogram',
>          target = 'fat_ramdisk.exe',
> diff --git a/rtems_waf b/rtems_waf
> index 1b89636..ad6c6e8 16
> --- a/rtems_waf
> +++ b/rtems_waf
> @@ -1 +1 @@
> -Subproject commit 1b896361d302aeda0145af90972aea863e28898f
> +Subproject commit ad6c6e8771b95dffa73a7dc1167d98d208f17cb0
> -- 
> 2.20.1
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add chapter for newib build in RTEMS Docs

2019-09-12 Thread Chris Johns 
On 13/9/19 8:42 am, Joel Sherrill wrote:
> On Thu, Sep 12, 2019 at 2:09 PM Gedare Bloom  wrote:
>>
>> Hello Vaibhav,
>>
>> It would be nice to provide such documentation, but I don't know that
>> we have an existing location that would be an ideal fit. I think the
>> topic is out of scope for User Manual. If you are motivated to write
>> something though, you could prepare it first as a standalone guide.
> 
> If we have a name for the document like "Maintainers Guide" or something,
> it could have a focus on procedures that only core developers would need.
> 
> + bootstrapping newlib and building it independently
> + modifying gcc, running tests,
> + submitting Coverity runs
> + running Doxygen
> + ...

These are all valid and important however can these reside in the Software
Engineering manual?

We current have ...

 1. RTEMS Software Engineering
 2. RTEMS Filesystem Design Guide
 3. RTEMS Development Environment Guide
 4. RTEMS BSP and Driver Guide

plus 'RTEMS BSP and Driver Guide' which I am not sure about. All these cover
some aspect of maintaining and developing RTEMS. Should we be considering
consolidation rather than expansion?

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

Re: Trying to interrupt a blocking read...

2019-09-12 Thread Benjamin Ellsworth 
It appears that VTIME does not work.  I set both VMIN and VTIME and I 
never get a timeout.  The read continues to happily block forever.


Also, when looking at VTIME handling down in the code, I see in 
termios.c the function fillBufferPoll().  It looks to me like that 
function expects (*tty->handler.poll_read) to return in less than 
tty->vtimeTicks in every case.  I don't see how that is guaranteed.


If (*tty->handler.poll_read) blocks until a byte shows up, then VTIME is 
basically meaningless.  I don't see any code that sends VTIME or 
vtimeTicks down to the underlying handler, so I don't see how the 
timeout could possibly be honored.


Or maybe there's something I don't understand...


Here is the function:

static void
fillBufferPoll (struct rtems_termios_tty *tty)
{
  int n;

  if (tty->termios.c_lflag & ICANON) {
for (;;) {
  n = (*tty->handler.poll_read)(tty->device_context);
  if (n < 0) {
rtems_task_wake_after (1);
  } else {
if  (siprocPoll (n, tty))
  break;
  }
}
  } else {
rtems_interval then, now;

then = rtems_clock_get_ticks_since_boot();
for (;;) {
  n = (*tty->handler.poll_read)(tty->device_context);
  if (n < 0) {
if (tty->termios.c_cc[VMIN]) {
  if (tty->termios.c_cc[VTIME] && tty->ccount) {
now = rtems_clock_get_ticks_since_boot();
if ((now - then) > tty->vtimeTicks) {
  break;
}
  }
} else {
  if (!tty->termios.c_cc[VTIME])
break;
  now = rtems_clock_get_ticks_since_boot();
  if ((now - then) > tty->vtimeTicks) {
break;
  }
}
rtems_task_wake_after (1);
  } else {
siprocPoll (n, tty);
if (tty->ccount >= tty->termios.c_cc[VMIN])
  break;
if (tty->termios.c_cc[VMIN] && tty->termios.c_cc[VTIME])
  then = rtems_clock_get_ticks_since_boot();
  }
}
  }
}


Or, maybe there's something I don't understand...

Thanks.



On 10-Sep-19 10:18 AM, Joel Sherrill wrote:

On Tue, Sep 10, 2019 at 12:09 AM Benjamin Ellsworth
<2gigspambuc...@gmail.com> wrote:


Hello,

The code I'm working with currently does a read() on a device that has
been opened with an open() call (a UART if that matters).  It nicely
blocks waiting for a character (potentially forever).

I now need that read to be interrupted...  I looked for pselect() so it
can block until I tell it to stop (via signal from another thread), but
that doesn't seem to be supported.  I looked at the classic work-around
using a pipe in a select call, but pipe() isn't supported and select
apparently only works on sockets (and the comments in the select header
make it sound like even that is a bad idea).


What version? I thought select() on termios devices was added at least
to the master.

You are right that it historically hasn't worked.

pipe() is supported. psxpipe01 is the test. Not sure about the use case
you have in mind.


I can probably make things work with timeouts--basically making it into
a polling loop, but I can't see a way to make the read timeout.  I dug
down into the rtems read functions, but didn't see any way to make them
timeout, nor did I see a way to cleanly interrupt them.


read() on a UART should be able to do non-blocking or timeout on read()
with the VMIN and VTIME support from termios. There should be examples
of this around the net.


If anyone has any suggestions/ideas/pointers, I'd appreciate them.


--joel



Thanks.

___
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: Trying to interrupt a blocking read...

2019-09-12 Thread Benjamin Ellsworth 

Joel,

Thanks for responding.

Our vendor's development kit uses a variant of 4.11.

It doesn't look like pipes work with the select call, and again there 
are dire warnings in the select.h file about how it's not really a good 
function to use anyway.


I'll look at VMIN and VTIME.  Thank you very much for the pointer.

Thanks,
--Ben


On 10-Sep-19 10:18 AM, Joel Sherrill wrote:

On Tue, Sep 10, 2019 at 12:09 AM Benjamin Ellsworth
<2gigspambuc...@gmail.com> wrote:


Hello,

The code I'm working with currently does a read() on a device that has
been opened with an open() call (a UART if that matters).  It nicely
blocks waiting for a character (potentially forever).

I now need that read to be interrupted...  I looked for pselect() so it
can block until I tell it to stop (via signal from another thread), but
that doesn't seem to be supported.  I looked at the classic work-around
using a pipe in a select call, but pipe() isn't supported and select
apparently only works on sockets (and the comments in the select header
make it sound like even that is a bad idea).


What version? I thought select() on termios devices was added at least
to the master.

You are right that it historically hasn't worked.

pipe() is supported. psxpipe01 is the test. Not sure about the use case
you have in mind.


I can probably make things work with timeouts--basically making it into
a polling loop, but I can't see a way to make the read timeout.  I dug
down into the rtems read functions, but didn't see any way to make them
timeout, nor did I see a way to cleanly interrupt them.


read() on a UART should be able to do non-blocking or timeout on read()
with the VMIN and VTIME support from termios. There should be examples
of this around the net.


If anyone has any suggestions/ideas/pointers, I'd appreciate them.


--joel



Thanks.

___
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: Add chapter for newib build in RTEMS Docs

2019-09-12 Thread Joel Sherrill 
On Thu, Sep 12, 2019 at 2:09 PM Gedare Bloom  wrote:
>
> Hello Vaibhav,
>
> It would be nice to provide such documentation, but I don't know that
> we have an existing location that would be an ideal fit. I think the
> topic is out of scope for User Manual. If you are motivated to write
> something though, you could prepare it first as a standalone guide.

If we have a name for the document like "Maintainers Guide" or something,
it could have a focus on procedures that only core developers would need.

+ bootstrapping newlib and building it independently
+ modifying gcc, running tests,
+ submitting Coverity runs
+ running Doxygen
+ ...

--joel

>
> On Tue, Aug 27, 2019 at 9:48 AM Vaibhav Gupta  
> wrote:
> >
> > Hello,
> > As RTEMS is using "Newlib" as its C library, sometimes RTEMS
> > developers need to contribute codes directly to it. For example in
> > my GSoC Project, I have to port various headers to Newlib.
> >
> > This requires building Newlib on local system, making changes,
> > using right autoconf-tools version, creating patches, etc.
> >
> > In my case I referred to the blogs of Aditya. Hesham gave me few advice
> > during weekly meeting.
> >
> > I was hoping if we can provide a separate chapter for this in RTEMS Docs 
> > User Manual.
> > It will be helpful for new developers and also new GSoC and GCI students.
> >
> > Is it okay to proceed with ?
> >
> > Vaibhav Gupta
> > ___
> > 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: Add chapter for newib build in RTEMS Docs

2019-09-12 Thread Gedare Bloom 
Hello Vaibhav,

It would be nice to provide such documentation, but I don't know that
we have an existing location that would be an ideal fit. I think the
topic is out of scope for User Manual. If you are motivated to write
something though, you could prepare it first as a standalone guide.

On Tue, Aug 27, 2019 at 9:48 AM Vaibhav Gupta  wrote:
>
> Hello,
> As RTEMS is using "Newlib" as its C library, sometimes RTEMS
> developers need to contribute codes directly to it. For example in
> my GSoC Project, I have to port various headers to Newlib.
>
> This requires building Newlib on local system, making changes,
> using right autoconf-tools version, creating patches, etc.
>
> In my case I referred to the blogs of Aditya. Hesham gave me few advice
> during weekly meeting.
>
> I was hoping if we can provide a separate chapter for this in RTEMS Docs User 
> Manual.
> It will be helpful for new developers and also new GSoC and GCI students.
>
> Is it okay to proceed with ?
>
> Vaibhav Gupta
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] Correct initial POSIX signals mask

2019-09-12 Thread Joel Sherrill 
+ Modify POSIX thread create extension to ensure expected
  initial signal mask is provided to system threads, initial
  tasks and threads, and inheritied by tasks and threads.
+ Adds psxsignal07 to verify functionality when using a POSIX
  Initialization thread and POSIX threads.
+ Adds psxsignal08 to verify functionality when using a Classic API
  Initialization task and Classic API tasks.

Closes #3794.
---
 cpukit/posix/src/pthreadcreate.c|  53 +++-
 testsuites/psxtests/Makefile.am |  22 
 testsuites/psxtests/configure.ac|   2 +
 testsuites/psxtests/psxsignal01/init.c  |  14 ++
 testsuites/psxtests/psxsignal02/init.c  |  14 ++
 testsuites/psxtests/psxsignal03/init.c  |  14 ++
 testsuites/psxtests/psxsignal07/main.c  | 136 
 testsuites/psxtests/psxsignal07/psxsignal07.doc |  23 
 testsuites/psxtests/psxsignal07/psxsignal07.scn |   7 +
 testsuites/psxtests/psxsignal07/rtems_config.c  |  44 +++
 testsuites/psxtests/psxsignal08/main.c  | 163 
 testsuites/psxtests/psxsignal08/psxsignal08.doc |  22 
 testsuites/psxtests/psxsignal08/psxsignal08.scn |   7 +
 testsuites/psxtests/psxsignal08/rtems_config.c  |  45 +++
 14 files changed, 561 insertions(+), 5 deletions(-)
 create mode 100644 testsuites/psxtests/psxsignal07/main.c
 create mode 100644 testsuites/psxtests/psxsignal07/psxsignal07.doc
 create mode 100644 testsuites/psxtests/psxsignal07/psxsignal07.scn
 create mode 100644 testsuites/psxtests/psxsignal07/rtems_config.c
 create mode 100644 testsuites/psxtests/psxsignal08/main.c
 create mode 100644 testsuites/psxtests/psxsignal08/psxsignal08.doc
 create mode 100644 testsuites/psxtests/psxsignal08/psxsignal08.scn
 create mode 100644 testsuites/psxtests/psxsignal08/rtems_config.c

diff --git a/cpukit/posix/src/pthreadcreate.c b/cpukit/posix/src/pthreadcreate.c
index 211b2cf..93e6fd8 100644
--- a/cpukit/posix/src/pthreadcreate.c
+++ b/cpukit/posix/src/pthreadcreate.c
@@ -86,7 +86,6 @@ int pthread_create(
   int low_prio;
   Priority_Controlcore_low_prio;
   POSIX_API_Control  *api;
-  const POSIX_API_Control*executing_api;
 #endif
 
   if ( !start_routine )
@@ -260,9 +259,6 @@ int pthread_create(
*  finish initializing the per API structure
*/
   api = the_thread->API_Extensions[ THREAD_API_POSIX ];
-  executing_api = executing->API_Extensions[ THREAD_API_POSIX ];
-
-  api->signals_unblocked = executing_api->signals_unblocked;
 
   _Priority_Node_set_priority( >Sporadic.Low_priority, core_low_prio );
   api->Sporadic.sched_ss_repl_period =
@@ -376,7 +372,7 @@ void _POSIX_Threads_Sporadic_budget_callout( Thread_Control 
*the_thread )
 }
 
 static bool _POSIX_Threads_Create_extension(
-  Thread_Control *executing RTEMS_UNUSED,
+  Thread_Control *executing,
   Thread_Control *created
 )
 {
@@ -389,6 +385,53 @@ static bool _POSIX_Threads_Create_extension(
   _Watchdog_Initialize( >Sporadic.Timer, _POSIX_Threads_Sporadic_timer );
   _Priority_Node_set_inactive( >Sporadic.Low_priority );
 
+#if defined(RTEMS_POSIX_API)
+  /*
+   * There are some subtle rules which need to be followed for
+   * the value of the created thread's signal mask. Because signals
+   * are part of C99 and enhanced by POSIX, both Classic API tasks
+   * and POSIX threads have to have them enabled.
+   *
+   * + Internal system threads should have no signals enabled. They
+   *   have no business executing user signal handlers -- especially IDLE.
+   * + The initial signal mask for other threads needs to follow the
+   *   implication of a pure C99 environment which only has the methods
+   *   raise() and signal(). This implies that all signals are unmasked
+   *   until the thread explicitly uses a POSIX methods to block some.
+   *   This applies to both Classic tasks and POSIX threads created
+   *   as initalization tasks/threads (e.g. before the system is up).
+   * + After the initial threads are created, the signal mask should
+   *   be inherited from the creator.
+   *
+   * NOTE: The default signal mask does not matter for any application
+   *   that does not use POSIX signals.
+   */
+  if ( _Objects_Get_API(created->Object.id) == OBJECTS_INTERNAL_API ) {
+  /*
+   * Ensure internal (especially IDLE) is handled first.
+   *
+   * Block signals for all internal threads -- especially IDLE.
+   */
+  api->signals_unblocked = 0;
+  } else if ( _Objects_Get_API(executing->Object.id) == OBJECTS_INTERNAL_API ) 
{
+  /*
+   * Threads being created while an internal thread is executing
+   * should only happen for the initialization threads/tasks.
+   *
+   * Default state (signals unblocked) for all Initialization tasks
+   * and POSIX threads. We should not inherit from IDLE which is
+

Re: [PATCH] Correct initial POSIX signals mask

2019-09-12 Thread Joel Sherrill 
On Thu, Sep 12, 2019 at 8:06 AM Sebastian Huber
 wrote:
>
> On 11/09/2019 01:11, Joel Sherrill wrote:
> > +  if (!_System_state_Is_up(_System_state_Get())) {
> > +if (_Objects_Get_API(created->Object.id) == OBJECTS_INTERNAL_API) {
>
> You have to add a couple of spaces to meet the coding style.

Gotcha.

> I would not use the system state, this could be a bit brittle on SMP
> systems. Can't you use the executing thread instead, e.g. if
> _Objects_Get_API( executing->Object.id ) == OBJECTS_INTERNAL_API, then
> api->signals_unblocked = SIGNAL_ALL_MASK?

I have changed it to

   if created == internal
 block all
   else if executing == internal
 unblock all for init threads/tasks
   else
 inherit

All tasks pass and I think this logic is correct.

V2 will be posted shortly.

Thanks for the comments.

--joel

> --
> 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] Correct initial POSIX signals mask

2019-09-12 Thread Sebastian Huber 

On 11/09/2019 01:11, Joel Sherrill wrote:

+  if (!_System_state_Is_up(_System_state_Get())) {
+if (_Objects_Get_API(created->Object.id) == OBJECTS_INTERNAL_API) {


You have to add a couple of spaces to meet the coding style.

I would not use the system state, this could be a bit brittle on SMP 
systems. Can't you use the executing thread instead, e.g. if 
_Objects_Get_API( executing->Object.id ) == OBJECTS_INTERNAL_API, then 
api->signals_unblocked = SIGNAL_ALL_MASK?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

2019-09-12 Thread Christian Mauderer 


On 12/09/2019 10:28, Vijay Kumar Banerjee wrote:
> 
> 
> 
> On Wed, Sep 11, 2019 at 4:38 PM Christian Mauderer
>  > wrote:
> 
> On 11/09/2019 10:48, Vijay Kumar Banerjee wrote:
> >
> >  Hi,
> >
> > Since adding I2C in BBB initialization seems like the right solution,
> > should we ask
> > in devel and user lists in a separate thread, to know if anyone is
> > opposed to this change?
> 
> Hello Vijay,
> 
> just send a patch. That will start the discussion if someone objects
> to it.
> 
> >
> > Where should I be looking for to add i2c in BBB initialization?
> 
> Please take a look at the dependencies. If there are any (like clocks or
> similar) you have to add it afterwards.
> 
> Take a look at some other BSPs where similar hardware (like I2C, SPI,
> some external chips, ...) is initialized. For example the mvme3100 uses
> a RTEMS_SYSINIT_ITEM to pick a random sample. But I think most BSPs use
> a special init function similar to the one in BBB.
> 
> Hi,
> 
> I tried a very similar approach and added RTEMS_SYSINIT_ITEM
> :
> ```
> diff --git a/bsps/arm/beagle/start/bspstart.c
> b/bsps/arm/beagle/start/bspstart.c
> index 224f9ecf3b..35839e774b 100644
> --- a/bsps/arm/beagle/start/bspstart.c
> +++ b/bsps/arm/beagle/start/bspstart.c
> @@ -17,6 +17,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "bspdebug.h"
>  
> @@ -41,3 +43,15 @@ uint32_t bsp_fdt_map_intr(const uint32_t *intr,
> size_t icells)
>  {
>    return intr[0];
>  }
> +
> +static void bbb_i2c_0_initialize(void)
> +{
> +  bbb_register_i2c_0();
> +}
> +
> +RTEMS_SYSINIT_ITEM(
> +  bbb_i2c_0_initialize,
> +  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
> +  RTEMS_SYSINIT_ORDER_MIDDLE
> +);
> ``` 
> This is successfully calling the `am335x_i2c_bus_register` but
> the issue with this approach is that it's returning the following
> internal error after `am335x_i2c_reset` call.
> ```
> _Terminate (the_source=the_source@entry=INTERNAL_ERROR_CORE,
> the_error=the_error@entry=30)
> ```
> 
> Any hint on what might be the cause of the error?

Just a guess: Are you sure that "BSP_PRE_DRIVERS" is the right order?
It's a driver so maybe somewhen during the drivers?

Does bbb_i2c_0_initialize has a type that is compatible with the sysinit
items?

> 
> Best regards
> 
> Christian
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

2019-09-12 Thread Vijay Kumar Banerjee 
On Wed, Sep 11, 2019 at 4:38 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 11/09/2019 10:48, Vijay Kumar Banerjee wrote:
> >
> >  Hi,
> >
> > Since adding I2C in BBB initialization seems like the right solution,
> > should we ask
> > in devel and user lists in a separate thread, to know if anyone is
> > opposed to this change?
>
> Hello Vijay,
>
> just send a patch. That will start the discussion if someone objects to it.
>
> >
> > Where should I be looking for to add i2c in BBB initialization?
>
> Please take a look at the dependencies. If there are any (like clocks or
> similar) you have to add it afterwards.
>
> Take a look at some other BSPs where similar hardware (like I2C, SPI,
> some external chips, ...) is initialized. For example the mvme3100 uses
> a RTEMS_SYSINIT_ITEM to pick a random sample. But I think most BSPs use
> a special init function similar to the one in BBB.
>
> Hi,

I tried a very similar approach and added RTEMS_SYSINIT_ITEM
:
```
diff --git a/bsps/arm/beagle/start/bspstart.c
b/bsps/arm/beagle/start/bspstart.c
index 224f9ecf3b..35839e774b 100644
--- a/bsps/arm/beagle/start/bspstart.c
+++ b/bsps/arm/beagle/start/bspstart.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include "bspdebug.h"

@@ -41,3 +43,15 @@ uint32_t bsp_fdt_map_intr(const uint32_t *intr, size_t
icells)
 {
   return intr[0];
 }
+
+static void bbb_i2c_0_initialize(void)
+{
+  bbb_register_i2c_0();
+}
+
+RTEMS_SYSINIT_ITEM(
+  bbb_i2c_0_initialize,
+  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
+  RTEMS_SYSINIT_ORDER_MIDDLE
+);
```
This is successfully calling the `am335x_i2c_bus_register` but
the issue with this approach is that it's returning the following
internal error after `am335x_i2c_reset` call.
```
_Terminate (the_source=the_source@entry=INTERNAL_ERROR_CORE,
the_error=the_error@entry=30)
```

Any hint on what might be the cause of the error?

> Best regards
>
> Christian
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel