[PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd
Christian Mauderer
list at c-mauderer.de
Tue Sep 17 19:24:46 UTC 2019
On 17/09/2019 21:04, Vijay Kumar Banerjee wrote:
>
>
>
> On Tue, Sep 17, 2019 at 2:21 PM Christian Mauderer <list at c-mauderer.de
> <mailto: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>
> > <mailto: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>>
> > > <mailto: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`?
I agree that it is quite likely that udelay doesn't work correctly when
the system isn't booted yet. Most likely that's the reason for the error.
I'm not entirely sure whether the udelay has been there before I updated
the driver or whether I took it over from the FreeBSD driver. But it's
not really relevant. Most likely the times are either required by the
manual or they had been necessary during some tests.
The am335x_i2c_reset is only called during initialization (in that case
during am335x_i2c_bus_register). So it shouldn't be a problem to replace
them with a busy wait. You can use the rtems_counter_delay_nanoseconds()
for that.
>
> >
> > 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>
> > <mailto: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 <mailto:devel at rtems.org>
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
More information about the devel
mailing list