Re: [PATCH v4 0/3] [5-freebsd-12] Fix compilation for i386

2020-04-10 Thread Gedare Bloom
Someone familiar with libbsd can review these for pushing. The main
concern from my perspective would be the things under sys/net.

On Thu, Apr 9, 2020 at 7:57 AM Jan Sommer  wrote:
>
> This is the  backport for the 5-freebsd-12 branch to make rtems-libbsd 
> compile for i386 again:
> - It also introduces path-mappings to waf_libbsd.py as introduced here:
> https://lists.rtems.org/pipermail/devel/2020-February/057457.html
>
> Changes compared to v3:
> - iflib.c: Properly deactivate usage of ifc_cpus
> - subr_gtaskqueue.c: Deactivate BSD_ASSERT for i386 (will open a
>   discussion for that)
> - Could successfully run network tests (e.g. dhcpcd0x.exe on hardware)
>
> Changes compared to v2:
> - callout.h: Change the callout_reset_on macro
> - iflib.c: Do not use different callout* macro, but use the changed one
>
> Happy Easter,
>
>Jan
>
>
> Jan Sommer (3):
>   i386: Add missing files from FreeBSD
>   i386: Update build system
>   i386: Port to RTEMS
>
>  freebsd-org|2 +-
>  freebsd/sbin/sysctl/sysctl.c   |8 +
>  freebsd/sys/dev/pci/pci_pci.c  |2 +
>  freebsd/sys/i386/include/machine/cpufunc.h |2 +
>  freebsd/sys/kern/subr_gtaskqueue.c |4 +
>  freebsd/sys/net/iflib.c| 6771 
> 
>  freebsd/sys/net/iflib_private.h|   76 +
>  freebsd/sys/net/mp_ring.c  |  554 ++
>  freebsd/sys/net/mp_ring.h  |   75 +
>  freebsd/sys/sys/callout.h  |6 +
>  freebsd/sys/x86/include/machine/intr_machdep.h |  180 +
>  .../sys/{i386 => x86}/include/machine/legacyvar.h  |   26 +-
>  freebsd/sys/{i386/i386 => x86/x86}/legacy.c|   77 +-
>  libbsd.py  |   17 +-
>  rtemsbsd/i386/include/machine/clock.h  |2 +
>  rtemsbsd/include/rtems/bsd/local/opt_acpi.h|0
>  rtemsbsd/include/x86/legacyvar.h   |1 +
>  rtemsbsd/include/x86/specialreg.h  | 1074 
>  rtemsbsd/include/x86/x86_var.h |  156 +
>  waf_libbsd.py  |   13 +-
>  20 files changed, 9006 insertions(+), 40 deletions(-)
>  create mode 100644 freebsd/sys/net/iflib.c
>  create mode 100644 freebsd/sys/net/iflib_private.h
>  create mode 100644 freebsd/sys/net/mp_ring.c
>  create mode 100644 freebsd/sys/net/mp_ring.h
>  create mode 100644 freebsd/sys/x86/include/machine/intr_machdep.h
>  rename freebsd/sys/{i386 => x86}/include/machine/legacyvar.h (76%)
>  rename freebsd/sys/{i386/i386 => x86/x86}/legacy.c (89%)
>  create mode 100644 rtemsbsd/i386/include/machine/clock.h
>  create mode 100644 rtemsbsd/include/rtems/bsd/local/opt_acpi.h
>  create mode 100644 rtemsbsd/include/x86/legacyvar.h
>  create mode 100644 rtemsbsd/include/x86/specialreg.h
>  create mode 100644 rtemsbsd/include/x86/x86_var.h
>
> --
> 2.12.3
>
> ___
> 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 9/9] [waf] Add an option to build C++ sample applications

2020-04-10 Thread Hesham Almatary
Also similar to the legacy autotools (--disable-cxx), users might want
to disable building CXX apps from config.ini or the spec.

On Fri, 10 Apr 2020 at 21:45, Hesham Almatary
 wrote:
>
> On Fri, 10 Apr 2020 at 19:07, Sebastian Huber
>  wrote:
> >
> > Hello,
> >
> > C++ tests should be disabled if the configure didn't find a C++
> > compiler. Do we have an architecture without C++ support from the compiler?
> >
> Having clang++ doesn't mean it can still compile C++ apps. Similar to
> having to build newlib and compiler-rt (LLVM's flavour of libgcc)
> separately from the LLVM toolchain, for C++, we need to also build
> LLVM's libcxx(rt) and libunwind. I haven't tested those yet for RISC-V
> and I'm not sure if they build/work fine, hence I added that option.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH 1/9] [waf] Fatal error if the compiler can't be found

2020-04-10 Thread Hesham Almatary
I believe my other patch (that outputs COMPILER to config.ini) has
hidden this issue. I was getting it when I specify
--rtems-compiler=clang as in

> ./waf bsp_defaults --rtems-bsps=rv64imafdc_medany --rtems-compiler=clang > 
> config.ini

That didn't output COMPILER in config.ini. So during ./waf configure
the following line:
> value = cp.get(conf.variant, "COMPILER")

triggered an exception, and silently fall back to "gcc", and I didn't
know what went wrong. I don't think it might happen again now with my
other patch, but if any of those lines triggered another exception for
whatever reason, it will fall back to GCC.

> def get_compiler(conf, cp, variant):
 >   try:
 >   value = cp.get(conf.variant, "COMPILER")
 >   cp.remove_option(conf.variant, "COMPILER")
 >   value = no_unicode(value)
 >   check_compiler(conf, value)
 >   except configparser.NoOptionError:
 >   value="gcc"

I hope that clarifies things a little bit. I am OK with this patch not
being pushed.

On Fri, 10 Apr 2020 at 21:38, Sebastian Huber

 wrote:
>
> On 10/04/2020 22:38, Hesham Almatary wrote:
>
> Hello Sebastian,
>
> On Fri, 10 Apr 2020 at 20:23, Sebastian Huber
>  wrote:
>
> On 10/04/2020 12:39, Hesham Almatary wrote:
>
> Don't default to gcc if the compiler can't be found
>
> All options should have a default. I should be possible to build a BSP
> just with:
>
> [arch/bsp]
>
> This patch doesn't change that behaviour. You can still build a BSP
> without providing --rtems-compiler at all and it will default to GCC.
> However, this patch addresses the case when you provide an
> "--rtems-compiler=blah", where "blah" can't be found nor supported.
> For example, without this patch, if I pass "--rtems-compiler=clang"
> and it's not supported/found, it will fallback default to GCC silently
> without giving any errors. I don't think that's a desirable behaviour.
>
> Could you give me an example command line which shows the undesired behaviour?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH 9/9] [waf] Add an option to build C++ sample applications

2020-04-10 Thread Hesham Almatary
On Fri, 10 Apr 2020 at 19:07, Sebastian Huber
 wrote:
>
> Hello,
>
> C++ tests should be disabled if the configure didn't find a C++
> compiler. Do we have an architecture without C++ support from the compiler?
>
Having clang++ doesn't mean it can still compile C++ apps. Similar to
having to build newlib and compiler-rt (LLVM's flavour of libgcc)
separately from the LLVM toolchain, for C++, we need to also build
LLVM's libcxx(rt) and libunwind. I haven't tested those yet for RISC-V
and I'm not sure if they build/work fine, hence I added that option.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH 1/9] [waf] Fatal error if the compiler can't be found

2020-04-10 Thread Sebastian Huber

On 10/04/2020 22:38, Hesham Almatary wrote:


Hello Sebastian,

On Fri, 10 Apr 2020 at 20:23, Sebastian Huber
  wrote:

On 10/04/2020 12:39, Hesham Almatary wrote:


Don't default to gcc if the compiler can't be found

All options should have a default. I should be possible to build a BSP
just with:

[arch/bsp]


This patch doesn't change that behaviour. You can still build a BSP
without providing --rtems-compiler at all and it will default to GCC.
However, this patch addresses the case when you provide an
"--rtems-compiler=blah", where "blah" can't be found nor supported.
For example, without this patch, if I pass "--rtems-compiler=clang"
and it's not supported/found, it will fallback default to GCC silently
without giving any errors. I don't think that's a desirable behaviour.
Could you give me an example command line which shows the undesired 
behaviour?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/9] [waf] Fatal error if the compiler can't be found

2020-04-10 Thread Hesham Almatary
Hello Sebastian,

On Fri, 10 Apr 2020 at 20:23, Sebastian Huber
 wrote:
>
> On 10/04/2020 12:39, Hesham Almatary wrote:
>
> > Don't default to gcc if the compiler can't be found
>
> All options should have a default. I should be possible to build a BSP
> just with:
>
> [arch/bsp]
>
This patch doesn't change that behaviour. You can still build a BSP
without providing --rtems-compiler at all and it will default to GCC.
However, this patch addresses the case when you provide an
"--rtems-compiler=blah", where "blah" can't be found nor supported.
For example, without this patch, if I pass "--rtems-compiler=clang"
and it's not supported/found, it will fallback default to GCC silently
without giving any errors. I don't think that's a desirable behaviour.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


New Build System Update

2020-04-10 Thread Sebastian Huber

Hello,

I changed the RTEMS version to 6 and removed the bsp_specs in the branch 
with the new build system:


https://git.rtems.org/sebh/rtems.git/log/?h=build

The latest unstable RTEMS 6 tools from the RSB are now required to work 
with the new build system and GCC.


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


Re: [PATCH 0/0] Clang/LLVM for RTEMS Waf Build

2020-04-10 Thread Sebastian Huber

Hello Hesham,

thanks for your patches. I checked in most of them. Some with slight 
modifications.


I changed the RTEMS version to 6 and removed the bsp_specs. The latest 
unstable RTEMS 6 tools from the RSB are now required to work with the 
new build system and GCC.


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


Re: [PATCH 1/9] [waf] Fatal error if the compiler can't be found

2020-04-10 Thread Sebastian Huber

On 10/04/2020 12:39, Hesham Almatary wrote:


Don't default to gcc if the compiler can't be found


All options should have a default. I should be possible to build a BSP 
just with:


[arch/bsp]

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


Re: [PATCH v3] bsp/beagle: Update console to new Termios API.

2020-04-10 Thread Niteesh G. S.
On Fri, Apr 10, 2020 at 9:18 PM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> sorry for the late review. It somehow slipped my attention.
>
> Although I'm generally OK with it, my suggestion would be to move it
> after the release. It's a not strictly necessary change and therefore I
> don't want to potentially break stuff with it now.
>
Okay then, I will make the changes and will send the patches after the
release.

> I added some comments below:
>
> On 23/03/2020 11:28, G S Niteesh Babu wrote:
> > This patch updates the console driver to new Termios API.
> >
> > Update #3034
> > ---
> >  bsps/arm/beagle/console/console-config.c | 117 +--
> >  c/src/lib/libbsp/arm/beagle/Makefile.am  |   4 +-
> >  2 files changed, 69 insertions(+), 52 deletions(-)
> >
> > diff --git a/bsps/arm/beagle/console/console-config.c
> b/bsps/arm/beagle/console/console-config.c
> > index 78af5f6a93..b2246571f8 100644
> > --- a/bsps/arm/beagle/console/console-config.c
> > +++ b/bsps/arm/beagle/console/console-config.c
> > @@ -21,12 +21,15 @@
> >   *
> >   * Modified by Ben Gras  to make
> >   * interrupt-driven uart i/o work for beagleboards; beaglebone support
> added.
> > + *
> > + * Modified by Niteesh Babu G S 
> > + * Update console to new termios API.
> >   */
> >
> > -#include 
> >  #include 
> >
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -41,6 +44,8 @@
> >  #define TX_FIFO_E (1<<5)
> >  #define RX_FIFO_E (1<<0)
> >
> > +#define BEAGLE_UART0 "/dev/ttyS0"
> > +
> >  static uint8_t beagle_uart_get_register(uintptr_t addr, uint8_t i)
> >  {
> >uint8_t v;
> > @@ -65,77 +70,91 @@ static void beagle_uart_set_register(uintptr_t addr,
> uint8_t i, uint8_t val)
> >reg [i] = val;
> >  }
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_NS16550,
> > -#if CONSOLE_POLLED   /* option to facilitate running the tests */
> > -  .pDeviceFns = _fns_polled,
> > -#else
> > -  .pDeviceFns = _fns,
> > -#endif
> > -  .ulMargin = 16,
> > -  .ulHysteresis = 8,
> > -  .pDeviceParams = (void *) CONSOLE_BAUD,
> > -  .ulCtrlPort1 = BSP_CONSOLE_UART_BASE,
> > -  .ulDataPort = BSP_CONSOLE_UART_BASE,
> > -  .ulIntVector = BSP_CONSOLE_UART_IRQ,
> > -  .getRegister = beagle_uart_get_register,
> > -  .setRegister = beagle_uart_set_register,
> > -  .ulClock = UART_CLOCK,  /* 48MHz base clock */
> > -},
> > -};
> > -
> > -unsigned long Console_Configuration_Count = 1;
> > -
> > -static int init_needed = 1; // don't rely on bss being 0
> > +static ns16550_context uart_context;
> > +static void uart_write_polled( char c );
> >
> >  static void beagle_console_init(void)
> >  {
> > -  if(init_needed) {
> > -const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;
> > -CONSOLE_SYSC = 2;
> > -while ((CONSOLE_SYSS & 1) == 0)
> > -  ;
> > -if ((CONSOLE_LSR & (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) ==
> CONSOLE_LSR_THRE) {
> > -  CONSOLE_LCR = 0x83;
> > -  CONSOLE_DLL = div;
> > -  CONSOLE_DLM = (div >> 8) & 0xff;
> > -  CONSOLE_LCR = 0x03;
> > -  CONSOLE_ACR = 0x00;
> > -}
> > +  ns16550_context *ctx;
> > +  static bool initialized = false;
> >
> > -while ((CONSOLE_LSR & CONSOLE_LSR_TEMT) == 0)
> > -  ;
> > +  if ( initialized ) {
>
> You never set initialized to true. So this will never happen.
>
> > +return ;
> > +  }
> >
> > -CONSOLE_LCR = 0x80 | 0x03;
> > -CONSOLE_DLL = 0x00;
> > -CONSOLE_DLM = 0x00;
> > -CONSOLE_LCR = 0x03;
> > -CONSOLE_MCR = 0x03;
> > -CONSOLE_FCR = 0x07;
> > +  /*
> > +   * Don't rely on BSS being zeroed
> > +   */
> > +  memset(_context, 0, sizeof(uart_context));
> > +  ctx = _context;
> > +
> > +  ctx->port = BSP_CONSOLE_UART_BASE;
> > +  ctx->irq = BSP_CONSOLE_UART_IRQ;
> > +  ctx->set_reg = beagle_uart_set_register;
> > +  ctx->get_reg = beagle_uart_get_register;
> > +  ctx->initial_baud = CONSOLE_BAUD;
> > +  ctx->clock = UART_CLOCK;
> > +
> > +  const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;
>
> I would prefer declarations at the top of the function.
>
> > +  CONSOLE_SYSC = 2;
> > +  while ((CONSOLE_SYSS & 1) == 0)
> > +;
> > +  if ((CONSOLE_LSR & (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) ==
> CONSOLE_LSR_THRE) {
> >  CONSOLE_LCR = 0x83;
> >  CONSOLE_DLL = div;
> >  CONSOLE_DLM = (div >> 8) & 0xff;
> >  CONSOLE_LCR = 0x03;
> >  CONSOLE_ACR = 0x00;
> > -init_needed = 0;
> >}
> > +  while ((CONSOLE_LSR & CONSOLE_LSR_TEMT) == 0)
> > +;
> > +  CONSOLE_LCR = 0x80 | 0x03;
> > +  CONSOLE_DLL = 0x00;
> > +  CONSOLE_DLM = 0x00;
> > +  CONSOLE_LCR = 0x03;
> > +  CONSOLE_MCR = 0x03;
> > +  CONSOLE_FCR = 0x07;
> > +  CONSOLE_LCR = 0x83;
> > +  CONSOLE_DLL = div;
> > +  CONSOLE_DLM = (div >> 8) & 0xff;
> > +  CONSOLE_LCR = 0x03;
> > +  CONSOLE_ACR = 0x00;
> > +
> > +  BSP_output_char = uart_write_polled;
> >  }
> >
> >  #define CONSOLE_THR8 

Re: [PATCH 4/9] [waf] Fix assembling when compiling with Clang/LLVM

2020-04-10 Thread Sebastian Huber

On 10/04/2020 12:39, Hesham Almatary wrote:


Currently waf_lib only knows about nasm and gas, and automatically
sets the required flags for those. When building with Clang/LLVM
it gets confused about the assembler and fails to add the appropriate
flags.

This commit adds such needed flags to be able to handle assembling
.S files with Clang/LLVM, as expected by waf_lib asm tool.

It is really great that you figured out how this works.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH 7/9] [waf] Add -I and -L flags to pkgconfig for Clang/LLVM

2020-04-10 Thread Sebastian Huber

Hello,

On 10/04/2020 12:39, Hesham Almatary wrote:

---
  spec/build/bsps/RTEMS-BUILD-BSP-PKGCONFIG.yml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/spec/build/bsps/RTEMS-BUILD-BSP-PKGCONFIG.yml 
b/spec/build/bsps/RTEMS-BUILD-BSP-PKGCONFIG.yml
index aa8a874235..128cd7d302 100644
--- a/spec/build/bsps/RTEMS-BUILD-BSP-PKGCONFIG.yml
+++ b/spec/build/bsps/RTEMS-BUILD-BSP-PKGCONFIG.yml
@@ -18,7 +18,7 @@ content: |
Version: ${RTEMS_VERSION}
Description: RTEMS BSP ${ARCH}/${BSP_NAME}
Libs:
-  Cflags: -qrtems --specs bsp_specs -B$${libdir} $${CFLAGS}
+  Cflags: -qrtems -I$${libdir}/include -L$${libdir} -B$${libdir} $${CFLAGS}
  derived: false
  enabled-by: []
  header: ''


this breaks the GCC support unless we get rid of the bsp_specs in GCC 10.

What does clang do with the -B flags?

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


Re: [PATCH 9/9] [waf] Add an option to build C++ sample applications

2020-04-10 Thread Sebastian Huber

Hello,

C++ tests should be disabled if the configure didn't find a C++ 
compiler. Do we have an architecture without C++ support from the compiler?


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


Re: GCC 10 build status

2020-04-10 Thread Sebastian Huber

Hello,

I encountered also some new multiple definition errors. The reason for 
this is that GCC 10 defaults to -fno-common. This could likely also lead 
to issues in applications.


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


Clang with the new build system

2020-04-10 Thread suyash singh
I came to know about the new waf build system in RTEMS. How do I start to
work on clang static analysis of BSPs with the new build system?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] bsp/beagle: Update console to new Termios API.

2020-04-10 Thread Christian Mauderer
Hello Niteesh,

sorry for the late review. It somehow slipped my attention.

Although I'm generally OK with it, my suggestion would be to move it
after the release. It's a not strictly necessary change and therefore I
don't want to potentially break stuff with it now.

I added some comments below:

On 23/03/2020 11:28, G S Niteesh Babu wrote:
> This patch updates the console driver to new Termios API.
> 
> Update #3034
> ---
>  bsps/arm/beagle/console/console-config.c | 117 +--
>  c/src/lib/libbsp/arm/beagle/Makefile.am  |   4 +-
>  2 files changed, 69 insertions(+), 52 deletions(-)
> 
> diff --git a/bsps/arm/beagle/console/console-config.c 
> b/bsps/arm/beagle/console/console-config.c
> index 78af5f6a93..b2246571f8 100644
> --- a/bsps/arm/beagle/console/console-config.c
> +++ b/bsps/arm/beagle/console/console-config.c
> @@ -21,12 +21,15 @@
>   *
>   * Modified by Ben Gras  to make
>   * interrupt-driven uart i/o work for beagleboards; beaglebone support added.
> + *
> + * Modified by Niteesh Babu G S 
> + * Update console to new termios API.
>   */
>  
> -#include 
>  #include 
>  
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -41,6 +44,8 @@
>  #define TX_FIFO_E (1<<5)
>  #define RX_FIFO_E (1<<0)
>  
> +#define BEAGLE_UART0 "/dev/ttyS0"
> +
>  static uint8_t beagle_uart_get_register(uintptr_t addr, uint8_t i)
>  {
>uint8_t v;
> @@ -65,77 +70,91 @@ static void beagle_uart_set_register(uintptr_t addr, 
> uint8_t i, uint8_t val)
>reg [i] = val;
>  }
>  
> -console_tbl Console_Configuration_Ports [] = {
> -{
> -  .sDeviceName = "/dev/ttyS0",
> -  .deviceType = SERIAL_NS16550,
> -#if CONSOLE_POLLED   /* option to facilitate running the tests */
> -  .pDeviceFns = _fns_polled,
> -#else
> -  .pDeviceFns = _fns,
> -#endif
> -  .ulMargin = 16,
> -  .ulHysteresis = 8,
> -  .pDeviceParams = (void *) CONSOLE_BAUD,
> -  .ulCtrlPort1 = BSP_CONSOLE_UART_BASE,
> -  .ulDataPort = BSP_CONSOLE_UART_BASE,
> -  .ulIntVector = BSP_CONSOLE_UART_IRQ,
> -  .getRegister = beagle_uart_get_register,
> -  .setRegister = beagle_uart_set_register,
> -  .ulClock = UART_CLOCK,  /* 48MHz base clock */
> -},
> -};
> -
> -unsigned long Console_Configuration_Count = 1;
> -
> -static int init_needed = 1; // don't rely on bss being 0
> +static ns16550_context uart_context;
> +static void uart_write_polled( char c );
>  
>  static void beagle_console_init(void)
>  {
> -  if(init_needed) {
> -const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;
> -CONSOLE_SYSC = 2;
> -while ((CONSOLE_SYSS & 1) == 0)
> -  ;
> -if ((CONSOLE_LSR & (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) == 
> CONSOLE_LSR_THRE) {
> -  CONSOLE_LCR = 0x83;
> -  CONSOLE_DLL = div;
> -  CONSOLE_DLM = (div >> 8) & 0xff;
> -  CONSOLE_LCR = 0x03;
> -  CONSOLE_ACR = 0x00;
> -}
> +  ns16550_context *ctx;
> +  static bool initialized = false;
>  
> -while ((CONSOLE_LSR & CONSOLE_LSR_TEMT) == 0)
> -  ;
> +  if ( initialized ) {

You never set initialized to true. So this will never happen.

> +return ;
> +  }
>  
> -CONSOLE_LCR = 0x80 | 0x03;
> -CONSOLE_DLL = 0x00;
> -CONSOLE_DLM = 0x00;
> -CONSOLE_LCR = 0x03;
> -CONSOLE_MCR = 0x03;
> -CONSOLE_FCR = 0x07;
> +  /*
> +   * Don't rely on BSS being zeroed
> +   */
> +  memset(_context, 0, sizeof(uart_context));
> +  ctx = _context;
> +
> +  ctx->port = BSP_CONSOLE_UART_BASE;
> +  ctx->irq = BSP_CONSOLE_UART_IRQ;
> +  ctx->set_reg = beagle_uart_set_register;
> +  ctx->get_reg = beagle_uart_get_register;
> +  ctx->initial_baud = CONSOLE_BAUD;
> +  ctx->clock = UART_CLOCK;
> +
> +  const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;

I would prefer declarations at the top of the function.

> +  CONSOLE_SYSC = 2;
> +  while ((CONSOLE_SYSS & 1) == 0)
> +;
> +  if ((CONSOLE_LSR & (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) == 
> CONSOLE_LSR_THRE) {
>  CONSOLE_LCR = 0x83;
>  CONSOLE_DLL = div;
>  CONSOLE_DLM = (div >> 8) & 0xff;
>  CONSOLE_LCR = 0x03;
>  CONSOLE_ACR = 0x00;
> -init_needed = 0;
>}
> +  while ((CONSOLE_LSR & CONSOLE_LSR_TEMT) == 0)
> +;
> +  CONSOLE_LCR = 0x80 | 0x03;
> +  CONSOLE_DLL = 0x00;
> +  CONSOLE_DLM = 0x00;
> +  CONSOLE_LCR = 0x03;
> +  CONSOLE_MCR = 0x03;
> +  CONSOLE_FCR = 0x07;
> +  CONSOLE_LCR = 0x83;
> +  CONSOLE_DLL = div;
> +  CONSOLE_DLM = (div >> 8) & 0xff;
> +  CONSOLE_LCR = 0x03;
> +  CONSOLE_ACR = 0x00;
> +
> +  BSP_output_char = uart_write_polled;
>  }
>  
>  #define CONSOLE_THR8 (*(volatile uint8_t *) (BSP_CONSOLE_UART_BASE + 0x00))
>  
>  static void uart_write_polled( char c )
>  {
> -  if(init_needed) beagle_console_init();
> -
>while( ( CONSOLE_LSR & TX_FIFO_E ) == 0 )
>  ;
>CONSOLE_THR8 = c;
>  }
>  
> +rtems_status_code console_initialize(
> +  rtems_device_major_number major,
> +  rtems_device_minor_number minor,
> +  void *arg
> +)
> +{
> +  rtems_termios_initialize();
> +
> +  

Re: [PATCH 0/0] Clang/LLVM for RTEMS Waf Build

2020-04-10 Thread Joel Sherrill
On Fri, Apr 10, 2020 at 7:24 AM suyash singh 
wrote:

> Hello,
>
>  As part of my proposed Gsoc,
>
> I am trying to integrate clang static analyzer and UBSan in rtems.
>
> Both of them work with the build process of a project
>

We should likely start a new thread for discussing the GSoC project.

I think if it makes sense for your GSoC Project to be more forward looking
and focus on the new build system. Soon after we branch for the release, I
assume Sebastian will switch us to his new build system. With any luck,
this will be before your coding period starts. His work is on a branch in
his personal repository at git.rtems.org.

I seem to be drawn to static analysis and warnings. I have seen some
articles on tools that claim to fix bugs and I have thought about
contacting them and seeing if their tools can propose solutions to our
warnings and static analysis issues.

>
>
>
> On Fri, Apr 10, 2020, 5:23 PM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
>
>> Hello Suyash,
>>
>> These patches aren't for upstream RTEMS, so it's not relevant to your
>> project/query.
>>
>> That said, I am not sure what you are trying to do. Are you trying to
>> build/cross-compile RTEMS itself with Clang?
>>
>> On Fri, 10 Apr 2020 at 12:17, suyash singh 
>> wrote:
>>
>>> Now I can run scan-build from clang/llvm?
>>>
>>> Earlier I got error
>>> [image: image.png]
>>>
>>> In earlier mail you suggested me to use
>>> [1] https://github.com/CTSRD-CHERI/llvm-project
>>> [2]
>>> https://github.com/RTEMS/rtems/blob/d582d0e130a463842e27070a2e85ebc1acc7b71f/bsps/riscv/riscv/config/rv32iac_clang.cfg#L8
>>>
>>> to build RISC-V
>>>
>>> On Fri, Apr 10, 2020 at 4:09 PM Hesham Almatary <
>>> hesham.almat...@cl.cam.ac.uk> wrote:
>>>
 Hello,

 The following set of patches are a few fixes and added support to
 build RTEMS with Clang/LLVM from the new Waf build system, with RISC-V
 as the main target architecture.

 Best,
 Hesham
 ___
 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: [PATCH RSB 4/4] qemu-couverture: update to qemu-stable-4.0.0

2020-04-10 Thread Vijay Kumar Banerjee
On Fri, Apr 10, 2020, 7:03 PM Joel Sherrill  wrote:

> I pushed this. Thanks. This was actually on the list in the back of my
> mind but never got a ticket.
>
> Thanks!
Can you please also push the other 3 patches? The qemu-couverture build
depends on them.

>
>
> On Fri, Apr 10, 2020 at 5:24 AM Vijay Kumar Banerjee 
> wrote:
>
>>
>>
>> On Fri, Apr 10, 2020 at 9:53 AM Gedare Bloom  wrote:
>>
>>> How was it tested?
>>>
>>> I ran coverage analysis on leon3-qemu-cov, it's working fine with this
>> qemu-couverture
>> build.
>>
>>> On Thu, Apr 9, 2020 at 2:22 PM Vijay Kumar Banerjee 
>>> wrote:
>>> >
>>> > ---
>>> >  bare/config/devel/qemu-couverture-git-1.cfg | 16 +---
>>> >  bare/config/devel/qemu-couverture.bset  |  5 +++--
>>> >  2 files changed, 8 insertions(+), 13 deletions(-)
>>> >
>>> > diff --git a/bare/config/devel/qemu-couverture-git-1.cfg
>>> b/bare/config/devel/qemu-couverture-git-1.cfg
>>> > index 4ca79f8..0f5629e 100644
>>> > --- a/bare/config/devel/qemu-couverture-git-1.cfg
>>> > +++ b/bare/config/devel/qemu-couverture-git-1.cfg
>>> > @@ -13,7 +13,7 @@
>>> >  #
>>> >  # Couverture QEMU Version.
>>> >  #
>>> > -%define qemu_version e9299f7591c8ecf3389922f4e7672b6bc5deae71
>>> > +%define qemu_version 03a7fbcce52e0bca7f033ccba79e7856e82bb437
>>> >
>>> >  #
>>> >  # Couverture QEMU disables for this version.
>>> > @@ -23,21 +23,15 @@
>>> >  #
>>> >  # Couverture QEMU architectures for this version.
>>> >  #
>>> > -%define qemu_archs
>>> arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,sparc-softmmu
>>> > +%define qemu_archs arm-softmmu,i386-softmmu,ppc-softmmu,sparc-softmmu
>>> >
>>> >  #
>>> >  # Set Couverture-Qemu source from github.
>>> >  #
>>> >  %source set qemu --rsb-file=qemu-couverture-%{qemu_version}.tar.gz
>>> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
>>> > -%hash sha512 qemu-couverture-%{qemu_version}.tar.gz
>>> b0479eefb8f067b97828b411b89c6b4ba4097477425a83b7ae439a3c0980c52cdbbbd2b7c85edb412ffe7f20b1822b65be008a989c815ceff72a493e551bbb78
>>> > +%hash sha512 qemu-couverture-%{qemu_version}.tar.gz
>>> 4b1877f1e8a10508b161a2b65f8e862e2ffa5bfc36cb458cdcad4e8a71a384bbb28e7fb50555008b023691b8187d252870586b1435e31989d059692f53ad6e1c
>>> >
>>> >  #
>>> > -# Patch to send halt signal to qemu-system-or32 process when RTEMS
>>> terminates
>>> > +# The Qemu build instructions. We use 4.x.x Release 1.
>>> >  #
>>> > -%patch add qemu
>>> %{rtems_http_git}/rtems-tools/plain/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
>>> > -%hash sha256
>>> 0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
>>> 88cd5c9e6e2a6bab23bf049a6f4212ff00083b002b73dbe63b2fe9832717f19e
>>> > -
>>> > -#
>>> > -# The Qemu build instructions. We use 1.x.x Release 1.
>>> > -#
>>> > -%include %{_configdir}/qemu-1-1.cfg
>>> > +%include %{_configdir}/qemu-4-1.cfg
>>> > diff --git a/bare/config/devel/qemu-couverture.bset
>>> b/bare/config/devel/qemu-couverture.bset
>>> > index 64024a1..fd5547c 100644
>>> > --- a/bare/config/devel/qemu-couverture.bset
>>> > +++ b/bare/config/devel/qemu-couverture.bset
>>> > @@ -16,10 +16,11 @@ package:
>>> qemu-couverture-%{qemu_version}-%{_host}-%{release}
>>> >  %define _internal_autotools_path
>>> %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
>>> >
>>> >  devel/autotools-internal
>>> > +devel/capstone
>>> >  devel/libiconv-1.14-1
>>> >  devel/gettext-0.18.3.1-1
>>> >  devel/libffi-3.0.13-1
>>> >  devel/pixman-0.32.4-1
>>> > -devel/glib-2.39.3-1
>>> > -devel/dtc-1.4.1-1
>>> > +devel/glib-2.48.2-1
>>> > +devel/dtc-1.6.0-1
>>> >  devel/qemu-couverture-git-1
>>> > --
>>> > 2.21.1
>>> >
>>> > ___
>>> > 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: [PATCH RSB 4/4] qemu-couverture: update to qemu-stable-4.0.0

2020-04-10 Thread Joel Sherrill
I pushed this. Thanks. This was actually on the list in the back of my mind
but never got a ticket.



On Fri, Apr 10, 2020 at 5:24 AM Vijay Kumar Banerjee 
wrote:

>
>
> On Fri, Apr 10, 2020 at 9:53 AM Gedare Bloom  wrote:
>
>> How was it tested?
>>
>> I ran coverage analysis on leon3-qemu-cov, it's working fine with this
> qemu-couverture
> build.
>
>> On Thu, Apr 9, 2020 at 2:22 PM Vijay Kumar Banerjee 
>> wrote:
>> >
>> > ---
>> >  bare/config/devel/qemu-couverture-git-1.cfg | 16 +---
>> >  bare/config/devel/qemu-couverture.bset  |  5 +++--
>> >  2 files changed, 8 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/bare/config/devel/qemu-couverture-git-1.cfg
>> b/bare/config/devel/qemu-couverture-git-1.cfg
>> > index 4ca79f8..0f5629e 100644
>> > --- a/bare/config/devel/qemu-couverture-git-1.cfg
>> > +++ b/bare/config/devel/qemu-couverture-git-1.cfg
>> > @@ -13,7 +13,7 @@
>> >  #
>> >  # Couverture QEMU Version.
>> >  #
>> > -%define qemu_version e9299f7591c8ecf3389922f4e7672b6bc5deae71
>> > +%define qemu_version 03a7fbcce52e0bca7f033ccba79e7856e82bb437
>> >
>> >  #
>> >  # Couverture QEMU disables for this version.
>> > @@ -23,21 +23,15 @@
>> >  #
>> >  # Couverture QEMU architectures for this version.
>> >  #
>> > -%define qemu_archs
>> arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,sparc-softmmu
>> > +%define qemu_archs arm-softmmu,i386-softmmu,ppc-softmmu,sparc-softmmu
>> >
>> >  #
>> >  # Set Couverture-Qemu source from github.
>> >  #
>> >  %source set qemu --rsb-file=qemu-couverture-%{qemu_version}.tar.gz
>> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
>> > -%hash sha512 qemu-couverture-%{qemu_version}.tar.gz
>> b0479eefb8f067b97828b411b89c6b4ba4097477425a83b7ae439a3c0980c52cdbbbd2b7c85edb412ffe7f20b1822b65be008a989c815ceff72a493e551bbb78
>> > +%hash sha512 qemu-couverture-%{qemu_version}.tar.gz
>> 4b1877f1e8a10508b161a2b65f8e862e2ffa5bfc36cb458cdcad4e8a71a384bbb28e7fb50555008b023691b8187d252870586b1435e31989d059692f53ad6e1c
>> >
>> >  #
>> > -# Patch to send halt signal to qemu-system-or32 process when RTEMS
>> terminates
>> > +# The Qemu build instructions. We use 4.x.x Release 1.
>> >  #
>> > -%patch add qemu
>> %{rtems_http_git}/rtems-tools/plain/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
>> > -%hash sha256
>> 0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
>> 88cd5c9e6e2a6bab23bf049a6f4212ff00083b002b73dbe63b2fe9832717f19e
>> > -
>> > -#
>> > -# The Qemu build instructions. We use 1.x.x Release 1.
>> > -#
>> > -%include %{_configdir}/qemu-1-1.cfg
>> > +%include %{_configdir}/qemu-4-1.cfg
>> > diff --git a/bare/config/devel/qemu-couverture.bset
>> b/bare/config/devel/qemu-couverture.bset
>> > index 64024a1..fd5547c 100644
>> > --- a/bare/config/devel/qemu-couverture.bset
>> > +++ b/bare/config/devel/qemu-couverture.bset
>> > @@ -16,10 +16,11 @@ package:
>> qemu-couverture-%{qemu_version}-%{_host}-%{release}
>> >  %define _internal_autotools_path
>> %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
>> >
>> >  devel/autotools-internal
>> > +devel/capstone
>> >  devel/libiconv-1.14-1
>> >  devel/gettext-0.18.3.1-1
>> >  devel/libffi-3.0.13-1
>> >  devel/pixman-0.32.4-1
>> > -devel/glib-2.39.3-1
>> > -devel/dtc-1.4.1-1
>> > +devel/glib-2.48.2-1
>> > +devel/dtc-1.6.0-1
>> >  devel/qemu-couverture-git-1
>> > --
>> > 2.21.1
>> >
>> > ___
>> > 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: [PATCH v2] bsp/raspberrypi: Fix build warnings.

2020-04-10 Thread Joel Sherrill
Pushed.

I'm sorry. It is surprising but working  from home seems to create even
more work than being in the office. I am swamped. :(

--joel

On Fri, Apr 10, 2020 at 7:59 AM Niteesh G. S.  wrote:

> This patch has been unnoticed for a while.
> If the lack of testing is what is stopping from pushing it I am happy
> to test it on real hardware.
>
> But I can't come up with a good methodology for testing it.
> My initial thoughts were to generate a GPIO interrupt with no ISR.
> This would cause the default ISR to be called. But I am not familiar
> with RTEMS interrupt mechanism so I don't know if this would work or not.
>
> If this is a wrong way to test it, then please let me know of the
> right way.
>
> Thanks,
> Niteesh.
>
> On Tue, Mar 31, 2020 at 4:21 AM Gedare Bloom  wrote:
>
>> This looks right but I'm not able to try it out.
>>
>> On Sat, Mar 28, 2020 at 12:24 PM G S Niteesh Babu 
>> wrote:
>> >
>> > 1) _Memory_Initialize makes pointer from integer
>> > without a cast.
>> > 2) printf format error, expects %u but %lu provided.
>> > ---
>> >  bsps/arm/raspberrypi/irq/irq.c | 4 +++-
>> >  bsps/arm/raspberrypi/start/bspstarthooks.c | 2 ++
>> >  2 files changed, 5 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/bsps/arm/raspberrypi/irq/irq.c
>> b/bsps/arm/raspberrypi/irq/irq.c
>> > index 9e1bcfc1bc..835cdf97d9 100644
>> > --- a/bsps/arm/raspberrypi/irq/irq.c
>> > +++ b/bsps/arm/raspberrypi/irq/irq.c
>> > @@ -32,6 +32,8 @@
>> >  #include 
>> >  #include 
>> >
>> > +#include 
>> > +
>> >  #ifdef RTEMS_SMP
>> >  #include 
>> >  #include 
>> > @@ -157,7 +159,7 @@ void
>> bsp_interrupt_vector_disable(rtems_vector_number vector)
>> >
>> >  void bsp_interrupt_handler_default(rtems_vector_number vector)
>> >  {
>> > -printk("spurious interrupt: %lu\n", vector);
>> > +printk("spurious interrupt: %" PRIdrtems_vector_number "\n",
>> vector);
>> >  }
>> >
>> >  rtems_status_code bsp_interrupt_facility_initialize(void)
>> > diff --git a/bsps/arm/raspberrypi/start/bspstarthooks.c
>> b/bsps/arm/raspberrypi/start/bspstarthooks.c
>> > index fd6aa53059..eb6546db1c 100644
>> > --- a/bsps/arm/raspberrypi/start/bspstarthooks.c
>> > +++ b/bsps/arm/raspberrypi/start/bspstarthooks.c
>> > @@ -184,7 +184,9 @@ static void bsp_memory_initialize(void)
>> >  {
>> >_Memory_Initialize(
>> >  &_Memory_Areas[0],
>> > +(void *)
>> >
>> raspberrypi_mmu_config_table[ARMV7_CP15_START_WORKSPACE_ENTRY_INDEX].begin,
>> > +(void *)
>> >
>> raspberrypi_mmu_config_table[ARMV7_CP15_START_WORKSPACE_ENTRY_INDEX].end
>> >);
>> >  }
>> > --
>> > 2.17.1
>> >
>> > ___
>> > 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: [PATCH v2] bsp/raspberrypi: Fix build warnings.

2020-04-10 Thread Niteesh G. S.
This patch has been unnoticed for a while.
If the lack of testing is what is stopping from pushing it I am happy
to test it on real hardware.

But I can't come up with a good methodology for testing it.
My initial thoughts were to generate a GPIO interrupt with no ISR.
This would cause the default ISR to be called. But I am not familiar
with RTEMS interrupt mechanism so I don't know if this would work or not.

If this is a wrong way to test it, then please let me know of the
right way.

Thanks,
Niteesh.

On Tue, Mar 31, 2020 at 4:21 AM Gedare Bloom  wrote:

> This looks right but I'm not able to try it out.
>
> On Sat, Mar 28, 2020 at 12:24 PM G S Niteesh Babu 
> wrote:
> >
> > 1) _Memory_Initialize makes pointer from integer
> > without a cast.
> > 2) printf format error, expects %u but %lu provided.
> > ---
> >  bsps/arm/raspberrypi/irq/irq.c | 4 +++-
> >  bsps/arm/raspberrypi/start/bspstarthooks.c | 2 ++
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/bsps/arm/raspberrypi/irq/irq.c
> b/bsps/arm/raspberrypi/irq/irq.c
> > index 9e1bcfc1bc..835cdf97d9 100644
> > --- a/bsps/arm/raspberrypi/irq/irq.c
> > +++ b/bsps/arm/raspberrypi/irq/irq.c
> > @@ -32,6 +32,8 @@
> >  #include 
> >  #include 
> >
> > +#include 
> > +
> >  #ifdef RTEMS_SMP
> >  #include 
> >  #include 
> > @@ -157,7 +159,7 @@ void
> bsp_interrupt_vector_disable(rtems_vector_number vector)
> >
> >  void bsp_interrupt_handler_default(rtems_vector_number vector)
> >  {
> > -printk("spurious interrupt: %lu\n", vector);
> > +printk("spurious interrupt: %" PRIdrtems_vector_number "\n",
> vector);
> >  }
> >
> >  rtems_status_code bsp_interrupt_facility_initialize(void)
> > diff --git a/bsps/arm/raspberrypi/start/bspstarthooks.c
> b/bsps/arm/raspberrypi/start/bspstarthooks.c
> > index fd6aa53059..eb6546db1c 100644
> > --- a/bsps/arm/raspberrypi/start/bspstarthooks.c
> > +++ b/bsps/arm/raspberrypi/start/bspstarthooks.c
> > @@ -184,7 +184,9 @@ static void bsp_memory_initialize(void)
> >  {
> >_Memory_Initialize(
> >  &_Memory_Areas[0],
> > +(void *)
> >
> raspberrypi_mmu_config_table[ARMV7_CP15_START_WORKSPACE_ENTRY_INDEX].begin,
> > +(void *)
> >
> raspberrypi_mmu_config_table[ARMV7_CP15_START_WORKSPACE_ENTRY_INDEX].end
> >);
> >  }
> > --
> > 2.17.1
> >
> > ___
> > 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 3/9] [waf] Move bsp_specs flag to GCC only file

2020-04-10 Thread Hesham Almatary
---
 spec/build/bsps/RTEMS-BUILD-BSP-OPTLDFLAGS.yml  | 2 --
 spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTGCC.yml | 6 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/spec/build/bsps/RTEMS-BUILD-BSP-OPTLDFLAGS.yml 
b/spec/build/bsps/RTEMS-BUILD-BSP-OPTLDFLAGS.yml
index 75d4f6637f..85b53c2eec 100644
--- a/spec/build/bsps/RTEMS-BUILD-BSP-OPTLDFLAGS.yml
+++ b/spec/build/bsps/RTEMS-BUILD-BSP-OPTLDFLAGS.yml
@@ -1,8 +1,6 @@
 actions:
 - set-value:
   - -qrtems
-  - -specs
-  - bsp_specs
   - -B${TOP}/bsps/${ARCH}/shared/start
   - -B${TOP}/bsps/${ARCH}/${BSP_FAMILY}/start
 - substitute: null
diff --git a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTGCC.yml 
b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTGCC.yml
index 246e8df180..e77cafa5e4 100644
--- a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTGCC.yml
+++ b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTGCC.yml
@@ -18,6 +18,12 @@ actions:
 - substitute: null
 - find-program: null
 - env-assign: LD
+- set-value:
+  - -specs
+  - bsp_specs
+  - -B${TOP}/bsps/${ARCH}/shared/start
+  - -B${TOP}/bsps/${ARCH}/${BSP_FAMILY}/start
+- env-append: LDFLAGS
 - script: |
 load = "ar g++ gas gcc"
 if not is_windows_host:
--
2.17.1

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


[PATCH 7/9] [waf] Add -I and -L flags to pkgconfig for Clang/LLVM

2020-04-10 Thread Hesham Almatary
---
 spec/build/bsps/RTEMS-BUILD-BSP-PKGCONFIG.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/spec/build/bsps/RTEMS-BUILD-BSP-PKGCONFIG.yml 
b/spec/build/bsps/RTEMS-BUILD-BSP-PKGCONFIG.yml
index aa8a874235..128cd7d302 100644
--- a/spec/build/bsps/RTEMS-BUILD-BSP-PKGCONFIG.yml
+++ b/spec/build/bsps/RTEMS-BUILD-BSP-PKGCONFIG.yml
@@ -18,7 +18,7 @@ content: |
   Version: ${RTEMS_VERSION}
   Description: RTEMS BSP ${ARCH}/${BSP_NAME}
   Libs:
-  Cflags: -qrtems --specs bsp_specs -B$${libdir} $${CFLAGS}
+  Cflags: -qrtems -I$${libdir}/include -L$${libdir} -B$${libdir} $${CFLAGS}
 derived: false
 enabled-by: []
 header: ''
--
2.17.1

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


[PATCH 2/9] [waf] Out COMPILER value from bsp_defaults for later confiugre

2020-04-10 Thread Hesham Almatary
configure reads this from config.ini and uses it later. Otherwise,
there is no other way to pass 'COMPILER' from bsp_defaults's options to
configure and it's assigned None.
---
 wscript | 1 +
 1 file changed, 1 insertion(+)

diff --git a/wscript b/wscript
index c0a3fd31e8..c763e214f6 100755
--- a/wscript
+++ b/wscript
@@ -1409,6 +1409,7 @@ def bsp_defaults(ctx):
 if first:
 no_matches_error(ctx, white_list)

+print("COMPILER = " + compiler)

 def bsp_list(ctx):
 """lists base BSP variants"""
--
2.17.1

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


[PATCH 5/9] [waf] Add a new ARCH_BITS option to be used in Clang's -triple

2020-04-10 Thread Hesham Almatary
---
 .../cpukit/RTEMS-BUILD-CPUKIT-CPUOPTS.yml |  1 +
 .../cpukit/RTEMS-BUILD-CPUKIT-OPTARCHBITS.yml | 30 +++
 2 files changed, 31 insertions(+)
 create mode 100644 spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTARCHBITS.yml

diff --git a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-CPUOPTS.yml 
b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-CPUOPTS.yml
index 387b2ec600..c9eeb82c6c 100644
--- a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-CPUOPTS.yml
+++ b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-CPUOPTS.yml
@@ -36,6 +36,7 @@ links:
 - RTEMS-BUILD-CPUKIT-OPTVERMIN: UfZbGW-lDbMcDS4hrZuRApdTdP9df1Ar4XTjUKRObJ4=
 - RTEMS-BUILD-CPUKIT-OPTVERREV: Wst9lX5qtktoqDIPzn-wD3gW6ha7LY5zTDjfk4ceCuA=
 - RTEMS-BUILD-CPUKIT-OPTVERSION: i3xHPoF-3mlKybTcTNFugN1JTbT5258-Z5l304N6riY=
+- RTEMS-BUILD-CPUKIT-OPTARCHBITS: ChapNb5NSPl062d5CnU251RB5J6TljFz_mLkmFdgwVY=
 normative: true
 order: -1000
 ref: ''
diff --git a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTARCHBITS.yml 
b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTARCHBITS.yml
new file mode 100644
index 00..f0cba94e4f
--- /dev/null
+++ b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTARCHBITS.yml
@@ -0,0 +1,30 @@
+actions:
+- get-string: null
+- split: null
+- env-append: null
+active: true
+build-type: option
+default: ''
+default-by-variant:
+- value:
+  - '64'
+  variants:
+  - riscv/rv64.*
+- value:
+  - '32'
+  variants:
+  - riscv/rv32.*
+derived: false
+enabled-by:
+- riscv
+- clang
+header: ''
+level: '1.110'
+links: []
+name: ARCH_BITS
+normative: true
+order: -1000
+ref: ''
+reviewed: ChapNb5NSPl062d5CnU251RB5J6TljFz_mLkmFdgwVY=
+text: ''
+type: build
--
2.17.1

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


[PATCH 0/0] Clang/LLVM for RTEMS Waf Build

2020-04-10 Thread Hesham Almatary
Hello,

The following set of patches are a few fixes and added support to
build RTEMS with Clang/LLVM from the new Waf build system, with RISC-V
as the main target architecture.

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


[PATCH 6/9] [waf][clang] Add required -target flag to ABI_FLAGS

2020-04-10 Thread Hesham Almatary
---
 spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTCLANG.yml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTCLANG.yml 
b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTCLANG.yml
index cac645e5ee..c5b218b5b1 100644
--- a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTCLANG.yml
+++ b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTCLANG.yml
@@ -22,6 +22,9 @@ actions:
 - set-value:
   - -o
 - env-assign: ASLNK_TGT_F
+- set-value: --target=${ARCH}${ARCH_BITS}-unknown-rtems${__RTEMS_MAJOR__}
+- substitute: null
+- env-append: ABI_FLAGS
 - script: |
 load = "ar asm clang clang++"
 if not is_windows_host:
--
2.17.1

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


[PATCH 8/9] [waf]: Fix ptimer.h -> timer.h header name in yml file

2020-04-10 Thread Hesham Almatary
---
 spec/build/cpukit/RTEMS-BUILD-CPUKIT-LIBRTEMSCPU.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-LIBRTEMSCPU.yml 
b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-LIBRTEMSCPU.yml
index 1d956173f0..2b473acb51 100644
--- a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-LIBRTEMSCPU.yml
+++ b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-LIBRTEMSCPU.yml
@@ -236,7 +236,7 @@ install:
   - cpukit/include/rtems/posix/pthread.h
   - cpukit/include/rtems/posix/pthreadattrimpl.h
   - cpukit/include/rtems/posix/pthreadimpl.h
-  - cpukit/include/rtems/posix/ptimer.h
+  - cpukit/include/rtems/posix/timer.h
   - cpukit/include/rtems/posix/rwlockimpl.h
   - cpukit/include/rtems/posix/semaphore.h
   - cpukit/include/rtems/posix/semaphoreimpl.h
--
2.17.1

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


[PATCH 9/9] [waf] Add an option to build C++ sample applications

2020-04-10 Thread Hesham Almatary
Defaults to false
---
 .../testsuites/RTEMS-BUILD-TEST-GRPTOP.yml|  1 +
 .../testsuites/RTEMS-BUILD-TEST-OPTCXX.yml| 20 +++
 .../RTEMS-BUILD-TEST-SAMPLE-CDTEST.yml|  3 ++-
 .../RTEMS-BUILD-TEST-SAMPLE-FILEIO.yml|  3 ++-
 .../RTEMS-BUILD-TEST-SAMPLE-IOSTREAM.yml  |  3 ++-
 5 files changed, 27 insertions(+), 3 deletions(-)
 create mode 100644 spec/build/testsuites/RTEMS-BUILD-TEST-OPTCXX.yml

diff --git a/spec/build/testsuites/RTEMS-BUILD-TEST-GRPTOP.yml 
b/spec/build/testsuites/RTEMS-BUILD-TEST-GRPTOP.yml
index 55b3e92cdd..10549799a9 100644
--- a/spec/build/testsuites/RTEMS-BUILD-TEST-GRPTOP.yml
+++ b/spec/build/testsuites/RTEMS-BUILD-TEST-GRPTOP.yml
@@ -12,6 +12,7 @@ links:
 - RTEMS-BUILD-TEST-OPTADA: 5gTNi40j7gaW9SW8qbbN0mXpB8lhCVK3NzoAHBFtelg=
 - RTEMS-BUILD-TEST-OPTALL: tx4OoqkdzH-51Ht9q8gLMhL6IQadCDkX3CecSfMZePc=
 - RTEMS-BUILD-TEST-OPTBENCHMARKS: 5E6anmk09XjmvNUDbQBlRRISUEA9Z1yicJFYZ2lmoS0=
+- RTEMS-BUILD-TEST-OPTCXX: Hi8O4hzJGikUlY--K_wzPy6OEkX-L5X32JZp1QikeXE=
 - RTEMS-BUILD-TEST-OPTFS: xFUJdmqvQIfIujXnes-97pqTm0vT8cSn5HzecORvDU8=
 - RTEMS-BUILD-TEST-OPTLIB: tgOZr20BGAt-A7cRhQ3qqw9Dwchz6lNTueaWrZuVR6U=
 - RTEMS-BUILD-TEST-OPTMP: _hHruhYRZlpPqFigzPl4kzS125-dxQ2XlBDHsI6Fx0A=
diff --git a/spec/build/testsuites/RTEMS-BUILD-TEST-OPTCXX.yml 
b/spec/build/testsuites/RTEMS-BUILD-TEST-OPTCXX.yml
new file mode 100644
index 00..a2aa46e53c
--- /dev/null
+++ b/spec/build/testsuites/RTEMS-BUILD-TEST-OPTCXX.yml
@@ -0,0 +1,20 @@
+actions:
+- get-boolean: null
+- env-enable: null
+active: true
+build-type: option
+default: false
+default-by-variant: []
+derived: false
+enabled-by: []
+header: ''
+level: 1.12
+links: []
+name: BUILD_CXXTESTS
+normative: true
+order: -1000
+ref: ''
+reviewed: Hi8O4hzJGikUlY--K_wzPy6OEkX-L5X32JZp1QikeXE=
+text: |
+  Build the C++ test programs
+type: build
diff --git a/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-CDTEST.yml 
b/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-CDTEST.yml
index dcb0270f43..7c4bc19df0 100644
--- a/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-CDTEST.yml
+++ b/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-CDTEST.yml
@@ -4,7 +4,8 @@ cflags: []
 cppflags: []
 cxxflags: []
 derived: false
-enabled-by: []
+enabled-by:
+- BUILD_CXXTESTS
 features: c cxx cxxprogram
 header: ''
 includes: []
diff --git a/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-FILEIO.yml 
b/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-FILEIO.yml
index 5c8620c793..498b0183e8 100644
--- a/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-FILEIO.yml
+++ b/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-FILEIO.yml
@@ -4,7 +4,8 @@ cflags: []
 cppflags: []
 cxxflags: []
 derived: false
-enabled-by: []
+enabled-by:
+- BUILD_CXXTESTS
 features: c cprogram
 header: ''
 includes: []
diff --git a/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-IOSTREAM.yml 
b/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-IOSTREAM.yml
index 75d9d48965..19aed15d05 100644
--- a/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-IOSTREAM.yml
+++ b/spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-IOSTREAM.yml
@@ -4,7 +4,8 @@ cflags: []
 cppflags: []
 cxxflags: []
 derived: false
-enabled-by: []
+enabled-by:
+- BUILD_CXXTESTS
 features: cxx cxxprogram
 header: ''
 includes: []
--
2.17.1

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


[PATCH 4/9] [waf] Fix assembling when compiling with Clang/LLVM

2020-04-10 Thread Hesham Almatary
Currently waf_lib only knows about nasm and gas, and automatically
sets the required flags for those. When building with Clang/LLVM
it gets confused about the assembler and fails to add the appropriate
flags.

This commit adds such needed flags to be able to handle assembling
.S files with Clang/LLVM, as expected by waf_lib asm tool.
---
 spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTCLANG.yml | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTCLANG.yml 
b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTCLANG.yml
index f75518931b..cac645e5ee 100644
--- a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTCLANG.yml
+++ b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTCLANG.yml
@@ -12,6 +12,16 @@ actions:
 - substitute: null
 - find-program: null
 - env-assign: AR
+- set-value: clang
+- env-assign: AS
+- env-assign: ASM_NAME
+- set-value:
+  - -c
+  - -o
+- env-assign: AS_TGT_F
+- set-value:
+  - -o
+- env-assign: ASLNK_TGT_F
 - script: |
 load = "ar asm clang clang++"
 if not is_windows_host:
--
2.17.1

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


[PATCH 1/9] [waf] Fatal error if the compiler can't be found

2020-04-10 Thread Hesham Almatary
Don't default to gcc if the compiler can't be found
---
 wscript | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/wscript b/wscript
index b135da74be..c0a3fd31e8 100755
--- a/wscript
+++ b/wscript
@@ -1232,7 +1232,8 @@ def get_compiler(conf, cp, variant):
 value = no_unicode(value)
 check_compiler(conf, value)
 except configparser.NoOptionError:
-value = "gcc"
+conf.fatal('Compiler not found')
+
 return value


--
2.17.1

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


Re: [PATCH RSB 4/4] qemu-couverture: update to qemu-stable-4.0.0

2020-04-10 Thread Vijay Kumar Banerjee
On Fri, Apr 10, 2020 at 9:53 AM Gedare Bloom  wrote:

> How was it tested?
>
> I ran coverage analysis on leon3-qemu-cov, it's working fine with this
qemu-couverture
build.

> On Thu, Apr 9, 2020 at 2:22 PM Vijay Kumar Banerjee 
> wrote:
> >
> > ---
> >  bare/config/devel/qemu-couverture-git-1.cfg | 16 +---
> >  bare/config/devel/qemu-couverture.bset  |  5 +++--
> >  2 files changed, 8 insertions(+), 13 deletions(-)
> >
> > diff --git a/bare/config/devel/qemu-couverture-git-1.cfg
> b/bare/config/devel/qemu-couverture-git-1.cfg
> > index 4ca79f8..0f5629e 100644
> > --- a/bare/config/devel/qemu-couverture-git-1.cfg
> > +++ b/bare/config/devel/qemu-couverture-git-1.cfg
> > @@ -13,7 +13,7 @@
> >  #
> >  # Couverture QEMU Version.
> >  #
> > -%define qemu_version e9299f7591c8ecf3389922f4e7672b6bc5deae71
> > +%define qemu_version 03a7fbcce52e0bca7f033ccba79e7856e82bb437
> >
> >  #
> >  # Couverture QEMU disables for this version.
> > @@ -23,21 +23,15 @@
> >  #
> >  # Couverture QEMU architectures for this version.
> >  #
> > -%define qemu_archs
> arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,sparc-softmmu
> > +%define qemu_archs arm-softmmu,i386-softmmu,ppc-softmmu,sparc-softmmu
> >
> >  #
> >  # Set Couverture-Qemu source from github.
> >  #
> >  %source set qemu --rsb-file=qemu-couverture-%{qemu_version}.tar.gz
> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
> > -%hash sha512 qemu-couverture-%{qemu_version}.tar.gz
> b0479eefb8f067b97828b411b89c6b4ba4097477425a83b7ae439a3c0980c52cdbbbd2b7c85edb412ffe7f20b1822b65be008a989c815ceff72a493e551bbb78
> > +%hash sha512 qemu-couverture-%{qemu_version}.tar.gz
> 4b1877f1e8a10508b161a2b65f8e862e2ffa5bfc36cb458cdcad4e8a71a384bbb28e7fb50555008b023691b8187d252870586b1435e31989d059692f53ad6e1c
> >
> >  #
> > -# Patch to send halt signal to qemu-system-or32 process when RTEMS
> terminates
> > +# The Qemu build instructions. We use 4.x.x Release 1.
> >  #
> > -%patch add qemu
> %{rtems_http_git}/rtems-tools/plain/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
> > -%hash sha256
> 0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
> 88cd5c9e6e2a6bab23bf049a6f4212ff00083b002b73dbe63b2fe9832717f19e
> > -
> > -#
> > -# The Qemu build instructions. We use 1.x.x Release 1.
> > -#
> > -%include %{_configdir}/qemu-1-1.cfg
> > +%include %{_configdir}/qemu-4-1.cfg
> > diff --git a/bare/config/devel/qemu-couverture.bset
> b/bare/config/devel/qemu-couverture.bset
> > index 64024a1..fd5547c 100644
> > --- a/bare/config/devel/qemu-couverture.bset
> > +++ b/bare/config/devel/qemu-couverture.bset
> > @@ -16,10 +16,11 @@ package:
> qemu-couverture-%{qemu_version}-%{_host}-%{release}
> >  %define _internal_autotools_path
> %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
> >
> >  devel/autotools-internal
> > +devel/capstone
> >  devel/libiconv-1.14-1
> >  devel/gettext-0.18.3.1-1
> >  devel/libffi-3.0.13-1
> >  devel/pixman-0.32.4-1
> > -devel/glib-2.39.3-1
> > -devel/dtc-1.4.1-1
> > +devel/glib-2.48.2-1
> > +devel/dtc-1.6.0-1
> >  devel/qemu-couverture-git-1
> > --
> > 2.21.1
> >
> > ___
> > 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