Re: LLVM on openSUSE 15.1

2019-09-17 Thread Chris Johns 
On 18/9/19 3:36 pm, Sebastian Huber wrote:
> On 17/09/2019 08:07, Sebastian Huber wrote:
>>
>>
>> On 17/09/2019 08:07, Chris Johns wrote:
>>> On 17/9/19 3:32 pm, Sebastian Huber wrote:
 Hello,

 I didn't get far:

 config.status: creating t/wrap/automake-1.12
 + make -j 12 all
    GEN  automake
    GEN  aclocal
    GEN  t/ax/shell-no-trail-bslash
    GEN  doc/aclocal.1
    GEN  doc/automake.1
    GEN  runtest
    GEN  t/ax/test-defs.sh
    GEN  lib/Automake/Config.pm
    GEN  doc/aclocal-1.12.1
    GEN  doc/automake-1.12.1
 help2man: can't get `--help' info from automake-1.12
 Try `--no-discard-stderr' if option outputs to stderr
 make: *** [Makefile:4114: doc/automake-1.12.1] Error 255
>>> That is weird because this is what we build for gcc as we need autoconf to 
>>> boot
>>> strap RTEMS.
>>
>> This is indeed quite weird, I never had problems building automake before. I
>> will try to figure out what went wrong here.
> 
> We have configuration files for Automake 1.12.6. I fixed it like this:
> 
> https://git.rtems.org/rtems-source-builder/commit/?id=bf7b4ad68f0faa9a35e52ca1baafb6f72c0fb673
> 

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

Re: LLVM on openSUSE 15.1

2019-09-17 Thread Sebastian Huber 

On 17/09/2019 08:07, Sebastian Huber wrote:



On 17/09/2019 08:07, Chris Johns wrote:

On 17/9/19 3:32 pm, Sebastian Huber wrote:

Hello,

I didn't get far:

config.status: creating t/wrap/automake-1.12
+ make -j 12 all
   GEN  automake
   GEN  aclocal
   GEN  t/ax/shell-no-trail-bslash
   GEN  doc/aclocal.1
   GEN  doc/automake.1
   GEN  runtest
   GEN  t/ax/test-defs.sh
   GEN  lib/Automake/Config.pm
   GEN  doc/aclocal-1.12.1
   GEN  doc/automake-1.12.1
help2man: can't get `--help' info from automake-1.12
Try `--no-discard-stderr' if option outputs to stderr
make: *** [Makefile:4114: doc/automake-1.12.1] Error 255
That is weird because this is what we build for gcc as we need 
autoconf to boot

strap RTEMS.


This is indeed quite weird, I never had problems building automake 
before. I will try to figure out what went wrong here.


We have configuration files for Automake 1.12.6. I fixed it like this:

https://git.rtems.org/rtems-source-builder/commit/?id=bf7b4ad68f0faa9a35e52ca1baafb6f72c0fb673

--
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] Add lvgl/hello: Sample Hello world app using littleVGL and libbsd

2019-09-17 Thread Chris Johns 
On 18/9/19 7:31 am, Vijay Kumar Banerjee wrote:
> diff --git a/lvgl/hello/wscript b/lvgl/hello/wscript
> new file mode 100644
> index 000..c706491
> --- /dev/null
> +++ b/lvgl/hello/wscript
> @@ -0,0 +1,30 @@
> +# Copyright 2019 Vijay Kumar Banerjee (vijaykumar9...@gmail.com)
> +#
> +# This file's license is 2-clause BSD as in this distribution's LICENSE.2 
> file.
> +#
> +
> +import rtems_waf.rtems as rtems
> +import os
> +
> +def configure(conf):
> +rtems.check_lib_path(conf, lib = 'm')
> +rtems.check_lib_path(conf, lib = 'lvgl')
> +rtems.check_lib_path(conf, lib = 'bsd')

What happens if there is no liblvgl found? I could not see any conditional 
logic.

Do the examples build for the SPARC erc32 BSP without liblvgl and libbsd?

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

Re: [PATCH 0/1] Add i2c in Beagle initialization

2019-09-17 Thread Chris Johns 
On 18/9/19 8:03 am, Vijay Kumar Banerjee wrote:
> The following patch adds i2c device initialization in BBB.
> The intention is to have th i2c-0 device created during
> initialization so that the libbsd applications can use the
> RTEMS i2c device on Beaglebone black without the need to
> call the i2c register api from the application.
> 
> If there's no objection from the community then this can
> be merged to the master.

Christian, please push if you are ok with this change.

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

Re: [PATCH] update rtems_waf

2019-09-17 Thread Chris Johns 
On 17/9/19 6:49 pm, Christian Mauderer wrote:
> On 17/09/2019 08:51, Vijay Kumar Banerjee wrote:
>> On Fri, Sep 13, 2019 at 9:00 AM Chris Johns > > wrote:
>>
>> On 11/9/19 6:14 pm, Vijay Kumar Banerjee wrote:
>> > ping :)
>>
>> Sorry about the delay. OK to push.
>>
>> Hi,
>> Thanks for the review!
>> Can you please push this. :)
> 
> Pushed it.
> 

Thanks and I have fixed the commit email repo name in the git hook.

>> Also, the github descript for rtems-examples has the wrong link,
>> it needs to be updated to https://git.rtems.org/rtems-examples.
> 
> I don't have access to these. So I can't update it. Chris: Do you have
> access?

Yes and fixed. Thanks.

Chris
___
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-17 Thread Vijay Kumar Banerjee 
On Wed, Sep 18, 2019 at 12:54 AM Christian Mauderer 
wrote:

>
> > 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.
>
>
> This worked. I have posted a patch and started a discussion here:
https://lists.rtems.org/pipermail/devel/2019-September/027748.html
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/1] bsps/beagle: register i2c device at initialization

2019-09-17 Thread Vijay Kumar Banerjee 
---
 bsps/arm/beagle/i2c/bbb-i2c.c|  6 +++---
 bsps/arm/beagle/start/bspstart.c | 13 +
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/bsps/arm/beagle/i2c/bbb-i2c.c b/bsps/arm/beagle/i2c/bbb-i2c.c
index 37b88864b9..f705078085 100644
--- a/bsps/arm/beagle/i2c/bbb-i2c.c
+++ b/bsps/arm/beagle/i2c/bbb-i2c.c
@@ -186,16 +186,16 @@ static int am335x_i2c_reset( bbb_i2c_bus *bus )
 
   bus->con_reg = 0;
   regs->BBB_I2C_CON = bus->con_reg;
-  udelay( 5 );
+  rtems_counter_delay_nanoseconds(5000);
 
   regs->BBB_I2C_SYSC = AM335X_I2C_SYSC_SRST;
-  udelay( 1000 );
+  rtems_counter_delay_nanoseconds(100);
   regs->BBB_I2C_CON = AM335X_I2C_CON_I2C_EN;
 
   while ( !( regs->BBB_I2C_SYSS & AM335X_I2C_SYSS_RDONE )
   && timeout >= 0 ) {
 --timeout;
-udelay( 100 );
+  rtems_counter_delay_nanoseconds(10);
   }
 
   if ( timeout <= 0 ) {
diff --git a/bsps/arm/beagle/start/bspstart.c b/bsps/arm/beagle/start/bspstart.c
index 224f9ecf3b..aadb9e826f 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,14 @@ 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_LAST,
+  RTEMS_SYSINIT_ORDER_LAST
+);
-- 
2.20.1

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

[PATCH 0/1] Add i2c in Beagle initialization

2019-09-17 Thread Vijay Kumar Banerjee 
Hello,

The following patch adds i2c device initialization in BBB.
The intention is to have th i2c-0 device created during
initialization so that the libbsd applications can use the
RTEMS i2c device on Beaglebone black without the need to
call the i2c register api from the application.

If there's no objection from the community then this can
be merged to the master.

Best regards,
Vijay

Vijay Kumar Banerjee (1):
  bsps/beagle: register i2c device at initialization

 bsps/arm/beagle/i2c/bbb-i2c.c|  6 +++---
 bsps/arm/beagle/start/bspstart.c | 13 +
 2 files changed, 16 insertions(+), 3 deletions(-)

-- 
2.20.1

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

[PATCH v2] Add lvgl/hello: Sample Hello world app using littleVGL and libbsd

2019-09-17 Thread Vijay Kumar Banerjee 
---
 README |   2 +-
 lvgl/README|   6 ++
 lvgl/hello/test.c  | 154 +
 lvgl/hello/wscript |  30 +
 lvgl/wscript   |  13 
 wscript|   9 ++-
 6 files changed, 212 insertions(+), 2 deletions(-)
 create mode 100644 lvgl/README
 create mode 100644 lvgl/hello/test.c
 create mode 100644 lvgl/hello/wscript
 create mode 100644 lvgl/wscript

diff --git a/README b/README
index 99ca787..f1e127c 100644
--- a/README
+++ b/README
@@ -15,4 +15,4 @@ posix_api- POSIX API examples (no led)
 schedsim - RTEMS Scheduler Simulator examples
 ticker   - Ticker Variations
 uboot- U-Boot interaction examples
-
+lvgl_hello   - LittleVGL graphics app example using libbsd framebuffer driver
diff --git a/lvgl/README b/lvgl/README
new file mode 100644
index 000..866d0cd
--- /dev/null
+++ b/lvgl/README
@@ -0,0 +1,6 @@
+This folder contains a sample graphics app using littleVGL library and libbsd
+The generated exe file can be directly run using a JTAG debugger on a target
+with the right device tree or this can be converted into an image.
+
+For instructions on how to build the image or how to run the exe, please refer
+to the BSP documentation in https://docs.rtems.org
diff --git a/lvgl/hello/test.c b/lvgl/hello/test.c
new file mode 100644
index 000..c85bb35
--- /dev/null
+++ b/lvgl/hello/test.c
@@ -0,0 +1,154 @@
+/*
+ * Copyright (c) 2019 Vijay Kumar Banerjee .
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PRIO_SHELL 150
+#define STACK_SIZE_SHELL   (64 * 1024)
+
+#include 
+
+void
+libbsdhelper_start_shell(rtems_task_priority prio)
+{
+   rtems_status_code sc = rtems_shell_init(
+   "SHLL",
+   STACK_SIZE_SHELL,
+   prio,
+   CONSOLE_DEVICE_NAME,
+   false,
+   true,
+   NULL
+   );
+   assert(sc == RTEMS_SUCCESSFUL);
+}
+
+static void
+Init(rtems_task_argument arg)
+{
+   rtems_status_code sc;
+   int exit_code;
+   (void)arg;
+   static lv_color_t buf[LV_HOR_RES_MAX*10];
+   static lv_disp_buf_t disp_buf;
+
+   puts("\nRTEMS LVGL HELLO WORLD\n");
+   sc = rtems_bsd_initialize();
+   assert(sc == RTEMS_SUCCESSFUL);
+
+   lv_init();
+
+   fbdev_init();
+
+   lv_disp_buf_init(_buf, buf, NULL, LV_HOR_RES_MAX*10);
+
+   lv_disp_drv_t disp_drv;
+   lv_disp_drv_init(_drv);
+   disp_drv.buffer = _buf;
+   disp_drv.flush_cb = fbdev_flush;
+   lv_disp_drv_register(_drv);
+
+   lv_obj_t * label = lv_label_create(lv_scr_act(), NULL);
+   lv_label_set_text(label, "Hello world!");
+   lv_obj_align(label, NULL, LV_ALIGN_CENTER, 0, 0);
+
+   lv_tick_inc(5);
+   lv_task_handler();
+
+   /* Some time for USB device to be detected. */
+   libbsdhelper_start_shell(PRIO_SHELL);
+
+
+   exit(0);
+}
+
+/*
+ * Configure LibBSD.
+ */
+#define RTEMS_BSD_CONFIG_BSP_CONFIG
+#define RTEMS_BSD_CONFIG_TERMIOS_KQUEUE_AND_POLL
+#define RTEMS_BSD_CONFIG_INIT
+
+#include 
+
+/*
+ * Configure RTEMS.
+ */
+#define CONFIGURE_MICROSECONDS_PER_TICK 1000
+
+#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
+#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
+#define CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER
+#define CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER
+#define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
+
+#define CONFIGURE_FILESYSTEM_DOSFS
+#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 32
+
+#define CONFIGURE_UNLIMITED_OBJECTS
+#define CONFIGURE_UNIFIED_WORK_AREAS
+#define

Re: llvm on CentOS 7

2019-09-17 Thread dufault 


> On Sep 16, 2019, at 17:52 , Joel Sherrill  wrote:
> 
> I need to install that!

That’s in regards to:
>> 
>> You can also install “devtoolset-7” from the CentOS Software Collection Sig 
>> (https://wiki.centos.org/SpecialInterestGroup/SCLo).  I have that installed.
>> devtoolset-7-binutils.x86_64 2.28-11.el7  
>> @centos-sclo-rh
>> 
>> That will give you gcc 7.3.1 and friends:

This is the CentOS version of the formal Red Hat way to get required newer 
tools on existing systems, so it’s a good way to go.


Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

___
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-17 Thread Christian Mauderer 
On 17/09/2019 21:04, Vijay Kumar Banerjee wrote:
> 
> 
> 
> On Tue, Sep 17, 2019 at 2:21 PM Christian Mauderer  > wrote:
> 
> On 17/09/2019 08:46, Vijay Kumar Banerjee wrote:
> >
> >
> > On Thu, Sep 12, 2019 at 2:37 PM Christian Mauderer
> >  
> >  >> wrote:
> >
> >
> >
> >     On 12/09/2019 10:28, Vijay Kumar Banerjee wrote:
> >     >
> >     >
> >     >
> >     > On Wed, Sep 11, 2019 at 4:38 PM Christian Mauderer
> >     >  
> >      >
> >     >  
> >       >     >
> >     >     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?
> >
> > 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

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

2019-09-17 Thread Vijay Kumar Banerjee 
On Tue, Sep 17, 2019 at 2:21 PM Christian Mauderer 
wrote:

> On 17/09/2019 08:46, Vijay Kumar Banerjee wrote:
> >
> >
> > On Thu, Sep 12, 2019 at 2:37 PM Christian Mauderer
> >  > > wrote:
> >
> >
> >
> > 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?
> >
> > 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
> >

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

2019-09-17 Thread Christian Mauderer 
On 17/09/2019 08:46, Vijay Kumar Banerjee wrote:
> 
> 
> On Thu, Sep 12, 2019 at 2:37 PM Christian Mauderer
>  > wrote:
> 
> 
> 
> 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?
> 
> 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?

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

Re: [PATCH] update rtems_waf

2019-09-17 Thread Christian Mauderer 


On 17/09/2019 08:51, Vijay Kumar Banerjee wrote:
> 
> 
> 
> On Fri, Sep 13, 2019 at 9:00 AM Chris Johns  > wrote:
> 
> On 11/9/19 6:14 pm, Vijay Kumar Banerjee wrote:
> > ping :)
> 
> Sorry about the delay. OK to push.
> 
> Hi,
> Thanks for the review!
> Can you please push this. :)

Pushed it.

> Also, the github descript for rtems-examples has the wrong link,
> it needs to be updated to https://git.rtems.org/rtems-examples.

I don't have access to these. So I can't update it. Chris: Do you have
access?

> 
> Best regards,
> Vijay>
> Chris
> 
> >
> >
> > On Tue, Sep 3, 2019 at 7:04 PM Vijay Kumar Banerjee
> mailto:vijaykumar9...@gmail.com>
> >  >> 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: [PATCH] update rtems_waf

2019-09-17 Thread Vijay Kumar Banerjee 
On Fri, Sep 13, 2019 at 9:00 AM Chris Johns  wrote:

> On 11/9/19 6:14 pm, Vijay Kumar Banerjee wrote:
> > ping :)
>
> Sorry about the delay. OK to push.
>
> Hi,
Thanks for the review!
Can you please push this. :)
Also, the github descript for rtems-examples has the wrong link,
it needs to be updated to https://git.rtems.org/rtems-examples.

Best regards,
Vijay

> Chris
>
> >
> >
> > On Tue, Sep 3, 2019 at 7:04 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com
> > > 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: [PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

2019-09-17 Thread Vijay Kumar Banerjee 
On Thu, Sep 12, 2019 at 2:37 PM Christian Mauderer <
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
> >  > > 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?
>
> 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.

> 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
> 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: LLVM on openSUSE 15.1

2019-09-17 Thread Chris Johns 
On 17/9/19 4:07 pm, Sebastian Huber wrote:
> On 17/09/2019 08:07, Chris Johns wrote:
>> On 17/9/19 3:32 pm, Sebastian Huber wrote:
>>> Hello,
>>>
>>> I didn't get far:
>>>
>>> config.status: creating t/wrap/automake-1.12
>>> + make -j 12 all
>>>    GEN  automake
>>>    GEN  aclocal
>>>    GEN  t/ax/shell-no-trail-bslash
>>>    GEN  doc/aclocal.1
>>>    GEN  doc/automake.1
>>>    GEN  runtest
>>>    GEN  t/ax/test-defs.sh
>>>    GEN  lib/Automake/Config.pm
>>>    GEN  doc/aclocal-1.12.1
>>>    GEN  doc/automake-1.12.1
>>> help2man: can't get `--help' info from automake-1.12
>>> Try `--no-discard-stderr' if option outputs to stderr
>>> make: *** [Makefile:4114: doc/automake-1.12.1] Error 255
>> That is weird because this is what we build for gcc as we need autoconf to 
>> boot
>> strap RTEMS.
> 
> This is indeed quite weird, I never had problems building automake before. I
> will try to figure out what went wrong here.

It is the internal build and so could be a little different.

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

Re: LLVM on openSUSE 15.1

2019-09-17 Thread Sebastian Huber 

On 17/09/2019 08:07, Sebastian Huber wrote:



On 17/09/2019 08:07, Chris Johns wrote:

On 17/9/19 3:32 pm, Sebastian Huber wrote:

Hello,

I didn't get far:

config.status: creating t/wrap/automake-1.12
+ make -j 12 all
   GEN  automake
   GEN  aclocal
   GEN  t/ax/shell-no-trail-bslash
   GEN  doc/aclocal.1
   GEN  doc/automake.1
   GEN  runtest
   GEN  t/ax/test-defs.sh
   GEN  lib/Automake/Config.pm
   GEN  doc/aclocal-1.12.1
   GEN  doc/automake-1.12.1
help2man: can't get `--help' info from automake-1.12
Try `--no-discard-stderr' if option outputs to stderr
make: *** [Makefile:4114: doc/automake-1.12.1] Error 255
That is weird because this is what we build for gcc as we need 
autoconf to boot

strap RTEMS.


This is indeed quite weird, I never had problems building automake 
before. I will try to figure out what went wrong here.


Building it for a normal RTEMS package works fine:

../source-builder/sb-set-builder --prefix=/build/rtems/5 5/rtems-riscv 
--no-install

RTEMS Source Builder - Set Builder, 5 (4b7af073000d modified)
warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown
Build Set: 5/rtems-riscv
Build Set: 5/rtems-autotools.bset
Build Set: 5/rtems-autotools-internal.bset
config: tools/rtems-autoconf-2.69-1.cfg
package: autoconf-2.69-x86_64-linux-gnu-1
building: autoconf-2.69-x86_64-linux-gnu-1
sizes: autoconf-2.69-x86_64-linux-gnu-1: 7.497MB (installed: 0.000B)
cleaning: autoconf-2.69-x86_64-linux-gnu-1
config: tools/rtems-automake-1.12.6-1.cfg
package: automake-1.12.6-x86_64-linux-gnu-1
building: automake-1.12.6-x86_64-linux-gnu-1
sizes: automake-1.12.6-x86_64-linux-gnu-1: 8.088MB (installed: 0.000B)
cleaning: automake-1.12.6-x86_64-linux-gnu-1
cleaning: autoconf-2.69-x86_64-linux-gnu-1
cleaning: automake-1.12.6-x86_64-linux-gnu-1
Build Sizes: usage: 8.088MB total: 7.774GB (sources: 7.772GB, patches: 
1.957MB, installed 0.000B)


--
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: LLVM on openSUSE 15.1

2019-09-17 Thread Sebastian Huber 



On 17/09/2019 08:07, Chris Johns wrote:

On 17/9/19 3:32 pm, Sebastian Huber wrote:

Hello,

I didn't get far:

config.status: creating t/wrap/automake-1.12
+ make -j 12 all
   GEN  automake
   GEN  aclocal
   GEN  t/ax/shell-no-trail-bslash
   GEN  doc/aclocal.1
   GEN  doc/automake.1
   GEN  runtest
   GEN  t/ax/test-defs.sh
   GEN  lib/Automake/Config.pm
   GEN  doc/aclocal-1.12.1
   GEN  doc/automake-1.12.1
help2man: can't get `--help' info from automake-1.12
Try `--no-discard-stderr' if option outputs to stderr
make: *** [Makefile:4114: doc/automake-1.12.1] Error 255

That is weird because this is what we build for gcc as we need autoconf to boot
strap RTEMS.


This is indeed quite weird, I never had problems building automake 
before. I will try to figure out what went wrong here.


--
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: LLVM on openSUSE 15.1

2019-09-17 Thread Chris Johns 
On 17/9/19 3:32 pm, Sebastian Huber wrote:
> Hello,
> 
> I didn't get far:
> 
> config.status: creating t/wrap/automake-1.12
> + make -j 12 all
>   GEN  automake
>   GEN  aclocal
>   GEN  t/ax/shell-no-trail-bslash
>   GEN  doc/aclocal.1
>   GEN  doc/automake.1
>   GEN  runtest
>   GEN  t/ax/test-defs.sh
>   GEN  lib/Automake/Config.pm
>   GEN  doc/aclocal-1.12.1
>   GEN  doc/automake-1.12.1
> help2man: can't get `--help' info from automake-1.12
> Try `--no-discard-stderr' if option outputs to stderr
> make: *** [Makefile:4114: doc/automake-1.12.1] Error 255

That is weird because this is what we build for gcc as we need autoconf to boot
strap RTEMS.

> 
> I removed the swig build and ended up here:
> 
> CMake Error: The following variables are used in this project, but they are 
> set
> to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the CMake 
> files:
> /scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/scripts/Python/modules/readline/libedit_INCLUDE_DIRS
> 
>    used as include directory in directory
> /scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/scripts/Python/modules/readline
> 
> /scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Core/libedit_INCLUDE_DIRS
> 
>    used as include directory in directory
> /scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Core
> 
> /scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Host/libedit_INCLUDE_DIRS
> 
>    used as include directory in directory
> /scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Host
> 
> /scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Interpreter/libedit_INCLUDE_DIRS
> 
>    used as include directory in directory
> /scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Interpreter
> 
> libedit_LIBRARIES (ADVANCED)
>     linked by target "readline" in directory
> /scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/scripts/Python/modules/readline

Please disable lldb for you and try again? There is a toggle in the cfg file.

Removing lldb also means swig is not needed.

> I guess I will stick to the openSUSE package for LLVM.

I see this as a valid option for users however I personally would not link a
critical project to the update and upgrade cycle of a distro. If we move from
having LLVM used in some host tools to building RTEMS and applications with
clang things change. The 5/rtems-llvm support is about that and so I think it is
important we can build LLVM from source. Your help in doing this is needed,
welcomed and important. It is not urgent but is something we will need to deal 
with.

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