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

[Vijay Kumar Banerjee]

On Tue, Sep 17, 2019 at 2:21 PM Christian Mauderer <list at c-mauderer.de>
wrote:

> On 17/09/2019 08:46, Vijay Kumar Banerjee wrote:
> >
> >
> > On Thu, Sep 12, 2019 at 2:37 PM Christian Mauderer
> > <christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>> wrote:
> >
> >
> >
> >     On 12/09/2019 10:28, Vijay Kumar Banerjee wrote:
> >     >
> >     >
> >     >
> >     > On Wed, Sep 11, 2019 at 4:38 PM Christian Mauderer
> >     > <christian.mauderer at embedded-brains.de
> >     <mailto:christian.mauderer at embedded-brains.de>
> >     > <mailto:christian.mauderer at embedded-brains.de
> >     <mailto:christian.mauderer at 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 <bsp/irq-generic.h>
> >     >  #include <bsp/fdt.h>
> >     >  #include <bsp/linker-symbols.h>
> >     > +#include <bsp/i2c.h>
> >     > +#include <rtems/sysinit.h>
> >     >
> >     >  #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 at entry=INTERNAL_ERROR_CORE,
> >     > the_error=the_error at 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?
> >
> > I tried RTEMS_SYSINIT_DEVICE_DRIVERS, and eve RTEMS_SYSINIT_LAST,
> > but it doesn't seem to work. Maybe it needs to be called in a further
> > later stage.
>
> I think you have a debugger? Could you set a breakpoint to _Terminate
> and take a look at the back trace what caused the error?
>
> Hi,
I followed the error and figured out that the reason for the error was a
call to
`rtems_task_wake_after` which was coming from the `udelay()` call in bbb-i2c
in function `am335x_i2c_reset`. For now, commenting out the udelay calls
work
without error and I can also see the lvgl example working.

What is the use of udelay there? Can it be removed? if not, what's the
better way
to make a delay at system initialization than `rtems_task_wake_after`?

>
> >     Does bbb_i2c_0_initialize has a type that is compatible with the
> sysinit
> >     items?
> >
> > yes, I checked this. the function is called and it's reaching
> > am335x_i2c_* calls
> > but it's getting stuck somewhere between i2c_reset and pinmux. Am I
> possibly
> > missing some other drivers that it depends on?
> > Can you please point me to the doc/note where the init sequence is
> properly
> > described. Also, if there's some other bsp that has initialized a driver
> > at init, please
> > point me to that for reference.
> >
> >     >
> >     >     Best regards
> >     >
> >     >     Christian
> >     >
> >
> >     --
> >     --------------------------------------------
> >     embedded brains GmbH
> >     Herr Christian Mauderer
> >     Dornierstr. 4
> >     D-82178 Puchheim
> >     Germany
> >     email: christian.mauderer at embedded-brains.de
> >     <mailto:christian.mauderer at 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 at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190918/ebb35494/attachment-0002.html>