On Tue, Sep 17, 2019 at 2:21 PM Christian Mauderer <l...@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.maude...@embedded-brains.de > > <mailto:christian.maude...@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.maude...@embedded-brains.de > > <mailto:christian.maude...@embedded-brains.de> > > > <mailto:christian.maude...@embedded-brains.de > > <mailto: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 <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@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? > > > > 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.maude...@embedded-brains.de > > <mailto: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 > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
