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 Al
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
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
---
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..
---
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.y
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/w
---
.../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.ym
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/m
---
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-OPTCLAN
---
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/RTEM
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.y
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/LL
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_uni
Hello Gedare,
I copied that file from rv64imafd which has that copyright header
On Wed, 8 Apr 2020 at 18:04, Gedare Bloom wrote:
>
> This looks alright. I doubt EB has a copyright in this, though.
>
> On Wed, Apr 8, 2020, 4:04 AM Hesham Almatary
> wrote:
>>
>> ---
t;
> > Also bump the dtc base package version number.
> >
> > I thought we settled on 1.4.
> >
> > --joel
> >
> > On Tue, Apr 7, 2020 at 3:56 AM Hesham Almatary
> > mailto:hesham.almat...@cl.cam.ac.uk>> wrote:
> >
> > *
file mode 100644
index 000..30abd50
--- /dev/null
+++ b/tester/rtems/testing/bsps/rv64imafdc_medany.ini
@@ -0,0 +1,36 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2020 Hesham Almatary
+# Copyright 2018 embedded brains GmbH
+# All rights reserved.
+#
+# This file is part of the
* There is no all$ target in Spike
* There is no longer --with-fesvr flag since fesvr is source-inlined
by default
---
source-builder/config/spike-1-1.cfg | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/source-builder/config/spike-1-1.cfg
b/source-builder/config/spike-1-1
---
bare/config/devel/dtc.bset | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset
index d701f93..54521f6 100644
--- a/bare/config/devel/dtc.bset
+++ b/bare/config/devel/dtc.bset
@@ -4,4 +4,4 @@
%define release 1
-devel/d
* There is no all$ target in Spike
* There is no longer --with-fesvr flag since fesvr is source-inlined
by default
---
source-builder/config/spike-1-1.cfg | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/source-builder/config/spike-1-1.cfg
b/source-builder/config/spike-1-1
On Sun, 5 Apr 2020 at 21:00, Joel Sherrill wrote:
>
>
>
> On Sun, Apr 5, 2020 at 2:54 PM Hesham Almatary
> wrote:
>>
>> On Sun, 5 Apr 2020 at 20:31, Joel Sherrill wrote:
>> >
>> > RTEMS is using this hash: 50782bc5cf00bbaa3ac5200
Hello,
Apologies for the lag in replies (I have a lot on my plate atm).
Two notes about RISC-V support in Clang/LLVM support. First, RISC-V
support in there is relatively new, so it's not as mature as GCC and
it lacks some features. Second, the RTEMS backend in Clang itself
doesn't exist upstream
Hi Chris,
On Sun, 15 Mar 2020 at 21:09, Chris Johns wrote:
> Hi Hesham,
>
> This is a great addition to rtems_waf, some comments below.
>
> On 16/3/20 2:56 am, Hesham Almatary wrote:
> > ---
> > rtems.py | 85 +
On Mon, 16 Mar 2020 at 13:35, Sebastian Huber
wrote:
>
> On 16/03/2020 14:33, Hesham Almatary wrote:
>
> > Sebastian, I modified my patch set to properly add the XLEN option.
> > This should make it generic enough for other architectures to be built
> > with Clang/L
/967b62464bf39602f8b0f2baf57617ad74c3643d...cbe9d2a40fade836667fe2a910b9c2f85866699c
On Mon, 16 Mar 2020 at 13:04, Hesham Almatary wrote:
>
>
>
> On Mon, 16 Mar 2020 at 12:54, Sebastian Huber
> wrote:
>>
>>
>> On 16/03/2020 13:51, Hesham Almatary wrote:
>>
>> T
On Mon, 16 Mar 2020 at 12:54, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
> On 16/03/2020 13:51, Hesham Almatary wrote:
>
> Thanks Sebastian!
>
> I tried to follow your instructions for adding this as a new option, but
> unfortunately, XLEN didn
mLkmFdgwVY=
> +text: ''
> +type: build
grepping for XLEN only gets me:
> c4che/spec_build.pickle:133389:ssS'RTEMS-BUILD-CPUKIT-OPTXLEN'
> c4che/spec_build.pickle:133433:S'XLEN'
>
> c4che/spec_build.pickle:154984:S'--target=${ARCH}${XLEN}-unknown-rt
On Mon, 16 Mar 2020 at 11:53, Sebastian Huber
wrote:
>
> On 16/03/2020 12:39, Hesham Almatary wrote:
>
> > Hi Sebastian,
> >
> > I have pushed a few commits to my repo to support building RTEMS with
> > Clang/LLVM for RISC-V. Here are the changes [1]. Since I
Hi Sebastian,
I have pushed a few commits to my repo to support building RTEMS with
Clang/LLVM for RISC-V. Here are the changes [1]. Since I'm still
learning about Waf and the build system, I'd appreciate your input.
Most importantly, I want to know what's the right way to set "target"
and "xlen"
---
rtems.py | 85 +---
1 file changed, 62 insertions(+), 23 deletions(-)
diff --git a/rtems.py b/rtems.py
index ffb386f..f1ef4de 100644
--- a/rtems.py
+++ b/rtems.py
@@ -1,4 +1,5 @@
+# Copyright 2020 Hesham Almatary
# Copyright 2012-2016
On Wed, 11 Mar 2020 at 03:05, Utkarsh Rai wrote:
>
> Before specifying the interface I want to take your kind feedback on what
> all things would need to be done in the interface.
>
> By looking into the MMU description of ARM and x86, according to me, the
> implementation would have to be don
On Wed, 4 Mar 2020 at 08:55, Sebastian Huber
wrote:
>
> On 25/02/2020 12:54, Sebastian Huber wrote:
> > On 25/02/2020 11:00, Hesham Almatary wrote:
> >> On Mon, 24 Feb 2020 at 22:50, Chris Johns wrote:
> >>> On 21/2/20 11:11 pm, Sebastian Huber wrote:
> >&
On Tue, 25 Feb 2020 at 11:54, Sebastian Huber
wrote:
>
> On 25/02/2020 11:00, Hesham Almatary wrote:
> > On Mon, 24 Feb 2020 at 22:50, Chris Johns wrote:
> >> On 21/2/20 11:11 pm, Sebastian Huber wrote:
> >>> On 21/02/2020 12:26, Hesham Almatary wrote:
&g
On Mon, 24 Feb 2020 at 22:50, Chris Johns wrote:
>
> On 21/2/20 11:11 pm, Sebastian Huber wrote:
> > On 21/02/2020 12:26, Hesham Almatary wrote:
> >> On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
> >> wrote:
> >>> Hello Hesham,
> >>
ot to merge.
>
> --joel
>
> On Fri, Feb 21, 2020, 11:00 AM Hesham Almatary
> wrote:
>>
>> CoreMark's primary goals are simplicity and providing a method for testing
>> only a processor's core features.
>> It is used primarily here as a perf
l/21
[2] https://github.com/eembc/coremark/pull/19
> It should be made clear in the repo the license of the Coremark (APL
> 1.0 I believe)
>
That's included in the coremark repo itself. Do you suggest adding a
note in the commit message about the license?
> On Fri, Feb 21, 2
/benchmarks/coremark/wscript b/benchmarks/coremark/wscript
new file mode 100644
index 000..c2c225a
--- /dev/null
+++ b/benchmarks/coremark/wscript
@@ -0,0 +1,48 @@
+#-
+# SPDX-License-Identifier: BSD-2-Clause
+#
+# Copyright (c) 2020 Hesham Almatary
+#
+# This software was developed by SRI Inter
Hello Gedare,
I can mentor RISC-V related projects or co-mentor others I may have
experience with.
Regards,
Hesham
On Fri, 21 Feb 2020 at 05:41, Sebastian Huber
wrote:
>
> Hello Gedare,
>
> I probably have no time to be a mentor this year. It depends a bit on
> the project and the student. I ca
On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
wrote:
>
> Hello Hesham,
>
> On 20/02/2020 16:40, Hesham Almatary wrote:
> > Hello,
> >
> > Are there any progress updates to the Waf build system integration in RTEMS?
> >
> > I have pulled [1] and it s
On Wed, 19 Feb 2020 at 21:38, Joel Sherrill wrote:
>
>
>
> On Wed, Feb 19, 2020, 12:58 PM Gedare Bloom wrote:
>>
>> On Wed, Feb 19, 2020 at 9:45 AM suyash singh
>> wrote:
>> >
>> > sorry clicked reply instead of "reply all"
>> >
>> >
>> > I don't have any boards and experience. What interests m
Hello,
Are there any progress updates to the Waf build system integration in RTEMS?
I have pulled [1] and it seems like it hasn't got many updates since
December. I wonder what's still remaining/blocking to merge it, or at
least push it as a development branch (without re-writing history)
that ot
Thanks Jeff!
On Wed, 4 Dec 2019 at 14:53, Jeff Kubascik
wrote:
>
> Add a README for the new xen bsp.
> ---
> user/bsps/arm/xen.rst | 79 +++
> 1 file changed, 79 insertions(+)
> create mode 100644 user/bsps/arm/xen.rst
>
> diff --git a/user/bsps/arm/xen.
Fixes #3827
---
rtems/config/tools/rtems-tools-5-1.cfg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
b/rtems/config/tools/rtems-tools-5-1.cfg
index 89e5d19..289e68d 100644
--- a/rtems/config/tools/rtems-tools-5-1.cfg
+++ b/rtems/config/
Fixes #3827
---
rtems/config/tools/rtems-tools-5-1.cfg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
b/rtems/config/tools/rtems-tools-5-1.cfg
index c633093..89e5d19 100644
--- a/rtems/config/tools/rtems-tools-5-1.cfg
+++ b/rtems/config/
On Wed, 27 Nov 2019 at 12:53, Sebastian Huber
wrote:
>
> On 27/11/2019 13:26, Sebastian Huber wrote:
> >>
> * Can't find any "*.exe" after a default build:
> >>>
> >>> Ok, this is a bug, you should find the samples.
> >>>
> >> Is it reproducible?
> >
> > I will have a look at this later.
>
>
On Wed, 27 Nov 2019 at 11:59, Sebastian Huber
wrote:
>
> On 27/11/2019 12:49, Hesham Almatary wrote:
> > Hi Sebastian,
> >
> > Thanks for that great effort. I'd aim to use this build system for my
> > RISC-V development.
> >
> > I followed the user
On Tue, 26 Nov 2019 at 21:43, Joel Sherrill wrote:
>
>
>
> On Tue, Nov 26, 2019 at 2:06 PM Niteesh wrote:
>>
>> Do both raspberry pi and raspberrypi2 use the same BSP? If not how to build
>> for raspberry pi 2
>
>
> Yes both use the same BSP family with some configuration settings based on
> th
Hi Sebastian,
Thanks for that great effort. I'd aim to use this build system for my
RISC-V development.
I followed the user manual trying to build RISC-V targets and RTEMS
(aaf7f8b84) and here are a few comments:
* .waf bsp_defaults doesn't give an error when mistyping the BSP name,
but just out
ngs, please
> push
> with these fixed.
>
> On 21/11/19 3:57 am, Hesham Almatary wrote:
> > ---
> > tester/rt/test.py | 52 ++-
> > 1 file changed, 51 insertions(+), 1 deletion(-)
> >
> > diff --git a/tester/rt/test.py
---
tester/rt/test.py | 52 ++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/tester/rt/test.py b/tester/rt/test.py
index 3cd9b48..6b45b78 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -285,8 +285,58 @@ def generate_json_repor
---
tester/rt/test.py | 52 ++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/tester/rt/test.py b/tester/rt/test.py
index 3cd9b48..fded48c 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -285,8 +285,58 @@ def generate_json_repor
---
tester/rt/test.py | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/tester/rt/test.py b/tester/rt/test.py
index 3cd9b48..db83b77 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -285,8 +285,35 @@ def generate_json_report(args, reports, s
Both need POSIX support
---
testsuites/libtests/Makefile.am | 4
1 file changed, 4 insertions(+)
diff --git a/testsuites/libtests/Makefile.am b/testsuites/libtests/Makefile.am
index b7a102dc7f..a97a833966 100644
--- a/testsuites/libtests/Makefile.am
+++ b/testsuites/libtests/Makefile.am
@@ -
On Thu, 14 Nov 2019 at 07:27, Sebastian Huber
wrote:
>
> Hello Hesham,
>
> On 13/11/2019 16:32, Hesham Almatary wrote:
> > On Wed, 13 Nov 2019 at 14:48, Sebastian Huber
> > wrote:
> >>
> >> Hello Hesham,
> >>
> >> On 23/10/2019 15:50
On Wed, 13 Nov 2019 at 14:48, Sebastian Huber
wrote:
>
> Hello Hesham,
>
> On 23/10/2019 15:50, Hesham Almatary wrote:
> > Hi,
> >
> > I submitted a RFC patch series to be able to build RTEMS/RISC-V with
> > LLVM/Clang. I'd appreciate your feedback on
HTIF devices are not supported on RV32, so proxy a write system call
This syncs HTIF Console with riscv-pk (proxy kernel) to use 32-bit
HTIF syscalls on RV32 instead of 64-bit commands that are not atomic.
---
bsps/riscv/riscv/console/htif.c | 65 ++---
1 file changed,
---
rtemstoolkit/rld-rap.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/rtemstoolkit/rld-rap.cpp b/rtemstoolkit/rld-rap.cpp
index 455328a..809b6d1 100644
--- a/rtemstoolkit/rld-rap.cpp
+++ b/rtemstoolkit/rld-rap.cpp
@@ -1399,6 +1399,12 @@ namespace rld
bool
---
rtemstoolkit/rld-elf.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/rtemstoolkit/rld-elf.cpp b/rtemstoolkit/rld-elf.cpp
index 231f2bf..ffa3376 100644
--- a/rtemstoolkit/rld-elf.cpp
+++ b/rtemstoolkit/rld-elf.cpp
@@ -1189,6 +1189,11 @@ namespace rld
{ "m68k",EM_COLDFI
.long in RISC-V assembly is 4 bytes, while the address in riscv64
is 8 bytes (.quad). Moreover, RTEMS' libdl increases the symbols
pointer by sizeof(long) in C when iterating over global symbols.
---
linkers/rtems-syms.cpp | 8
1 file changed, 8 insertions(+)
diff --git a/linkers/rtems-s
---
testsuites/libtests/dl02/dl-load.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/testsuites/libtests/dl02/dl-load.c
b/testsuites/libtests/dl02/dl-load.c
index 2e76c2dea6..b7a5fc54d4 100644
--- a/testsuites/libtests/dl02/dl-load.c
+++ b/testsuites/libtests/dl02/dl-load.c
git a/cpukit/libdl/rtl-mdreloc-riscv.c b/cpukit/libdl/rtl-mdreloc-riscv.c
new file mode 100644
index 00..e6778dcc90
--- /dev/null
+++ b/cpukit/libdl/rtl-mdreloc-riscv.c
@@ -0,0 +1,435 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (c) 2019 Hesham Almatary
+ *
+ * This
On Thu, 31 Oct 2019 at 08:52, Sebastian Huber
wrote:
>
> On 29/10/2019 10:34, Hesham Almatary wrote:
> > This is to hide the new BSPs from GCC builds when building
> > all RISC-V BSPs with configure --target=riscv-rtems5
>
> Can you still build the clang variants after t
OK to push?
On Tue, 29 Oct 2019 at 09:25, Hesham Almatary
wrote:
>
> On Mon, 28 Oct 2019 at 23:15, Joel Sherrill wrote:
> >
> >
> >
> > On Mon, Oct 28, 2019 at 5:20 AM Hesham Almatary
> > wrote:
> >>
> >> On Mon, 28 Oct 2019 at 04:01, Ch
---
bsps/riscv/riscv/console/console-config.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/bsps/riscv/riscv/console/console-config.c
b/bsps/riscv/riscv/console/console-config.c
index 464b4b0e26..5226285272 100644
--- a/bsps/riscv/riscv/console/console-confi
This is to hide the new BSPs from GCC builds when building
all RISC-V BSPs with configure --target=riscv-rtems5
---
.../config/{rv32i_clang.cfg => rv32i_clang.ccfg} | 0
.../{rv32iac_clang.cfg => rv32iac_clang.ccfg} | 0
.../config/{rv32im_clang.cfg => rv32im_clang.ccfg} | 0
.../{rv32im
On Mon, 28 Oct 2019 at 23:15, Joel Sherrill wrote:
>
>
>
> On Mon, Oct 28, 2019 at 5:20 AM Hesham Almatary
> wrote:
>>
>> On Mon, 28 Oct 2019 at 04:01, Chris Johns wrote:
>> >
>> >
>> >
>> > On 28/10/19 9:21 am, Hesham Almatary
On Mon, 28 Oct 2019 at 10:33, Sebastian Huber
wrote:
>
> On 28/10/2019 11:16, Hesham Almatary wrote:
> > Hi Sebastian,
> >
> > The *_clang ones aren't expected to be compiled by GCC (and the native
> > *.cfg won't compile with clang). Is there a reason th
On Mon, 28 Oct 2019 at 04:01, Chris Johns wrote:
>
>
>
> On 28/10/19 9:21 am, Hesham Almatary wrote:
> >
> >
> > On Sun, 27 Oct 2019 at 20:54, Chris Johns > <mailto:chr...@rtems.org>> wrote:
> >
> > On 27/10/19 9:37 pm, Hesham Almatary wr
Hi Sebastian,
The *_clang ones aren't expected to be compiled by GCC (and the native
*.cfg won't compile with clang). Is there a reason they should be?
On Mon, 28 Oct 2019 at 07:42, Sebastian Huber
wrote:
>
> Hello,
>
> when you build the new clang variants with GCC you get:
>
> gmake[3]: Lea
On Sun, 27 Oct 2019 at 20:54, Chris Johns wrote:
> On 27/10/19 9:37 pm, Hesham Almatary wrote:
> > Yeah fesvr is now part of Spike in-tree. I didn't like it had to be
> > built separately either [1].
> >
> > Joel, AFAIR, dtc was always needed.
>
> Plea
s Johns wrote:
>>
>> On 24/10/19 7:57 pm, Hesham Almatary wrote:
>> > Latest Spike integrated fesvr in its source directory, so there
>> > is no separate fesvr anymore.
>>
>> Nice. Building and installing fesvr was a little unusual.
>>
>> Chris
Hi Sebastian,
On Thu, 24 Oct 2019 at 12:48, Sebastian Huber
wrote:
>
> Hello,
>
> I work currently on a new build system based on waf and Doorstop. It
> would be good to have the clang support at the top level of the build
> system. Doing this for the current build system is probably a waste of
>
---
bsps/riscv/riscv/config/rv32i_clang.cfg | 14 ++
bsps/riscv/riscv/config/rv32iac_clang.cfg| 14 ++
bsps/riscv/riscv/config/rv32im_clang.cfg | 14 ++
bsps/riscv/riscv/config/rv32imac_clang.cfg | 14 ++
bsps/riscv/riscv/config/rv32im
---
bsps/riscv/shared/start/linkcmds.base.in | 5 +
1 file changed, 5 insertions(+)
diff --git a/bsps/riscv/shared/start/linkcmds.base.in
b/bsps/riscv/shared/start/linkcmds.base.in
index 7d6a23cde0..d921e29fe4 100644
--- a/bsps/riscv/shared/start/linkcmds.base.in
+++ b/bsps/riscv/shared/star
This commit moves the existing linkcmds.base to linkcmds.base.in
in order to make it configurable by autotools.
---
bsps/riscv/shared/start/{linkcmds.base => linkcmds.base.in} | 0
c/src/lib/libbsp/riscv/riscv/Makefile.am| 2 +-
c/src/lib/libbsp/riscv/riscv/configure.ac
LLVM/LLD does not support STARTUP and ALIGN_WITH_INPUT directives that
GNU LD support. INPUT and ALIGN(8) are supported by LLVM/LLD and can
replace the unsupported STARTUP/ALIGN_WITH_INPUT directives.
The commit conditionally adds the supported directive that linkers
can understand depending on th
ld.lld defaults .work to PROGBITS otherwise
---
bsps/riscv/shared/start/linkcmds.base.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/riscv/shared/start/linkcmds.base.in
b/bsps/riscv/shared/start/linkcmds.base.in
index 857bf2dabd..7d6a23cde0 100644
--- a/bsps/riscv/sha
On Thu, 24 Oct 2019 at 09:59, Sebastian Huber
wrote:
>
> On 23/10/2019 15:44, Hesham Almatary wrote:
> > This commit moves the existing linkcmds.base to linkcmds.base.in
> > in order to make it configurable by autotools.
>
> This file is also used by the grisp BSP, does i
On Thu, 24 Oct 2019 at 09:55, Sebastian Huber
wrote:
>
> On 23/10/2019 15:44, Hesham Almatary wrote:
> > +# Clang-related flags
> > +CPU_CFLAGS += -target riscv64-unknown-rtems6 -D__rtems__
> > --sysroot=$(NEWLIB_SYSROOT)
>
> Was clang configured to support this ta
On Thu, 24 Oct 2019 at 09:58, Sebastian Huber
wrote:
>
> On 23/10/2019 15:44, Hesham Almatary wrote:
> > LLVM/LLD does not support STARTUP and ALIGN_WITH_INPUT directives that
> > GNU LD support. INPUT and ALIGN(8) are supported by LLVM/LLD and can
> > replace
Latest Spike integrated fesvr in its source directory, so there
is no separate fesvr anymore.
Also use a revision of Spike that fixes the file permissions
when getting installed.
---
bare/config/devel/spike-1.1.0.cfg | 12 ++--
source-builder/config/spike-1-1.cfg | 22 ++
Hi,
I submitted a RFC patch series to be able to build RTEMS/RISC-V with
LLVM/Clang. I'd appreciate your feedback on that.
A sample configure line to build RTEMS with LLVM/Clang is:
../rtems/configure --target=riscv-rtems6
--enable-rtemsbsp=rv64imafdc_clang CC_FOR_TARGET="clang"
CXX_FOR_TARGET=
---
bsps/riscv/shared/start/linkcmds.base.in | 5 +
1 file changed, 5 insertions(+)
diff --git a/bsps/riscv/shared/start/linkcmds.base.in
b/bsps/riscv/shared/start/linkcmds.base.in
index 7d6a23cde0..d921e29fe4 100644
--- a/bsps/riscv/shared/start/linkcmds.base.in
+++ b/bsps/riscv/shared/star
LLVM/LLD does not support STARTUP and ALIGN_WITH_INPUT directives that
GNU LD support. INPUT and ALIGN(8) are supported by LLVM/LLD and can
replace the unsupported STARTUP/ALIGN_WITH_INPUT directives.
The commit conditionally adds the supported directive that linkers
can understand depending on th
ld.lld defaults .work to PROGBITS otherwise
---
bsps/riscv/shared/start/linkcmds.base.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/riscv/shared/start/linkcmds.base.in
b/bsps/riscv/shared/start/linkcmds.base.in
index 857bf2dabd..7d6a23cde0 100644
--- a/bsps/riscv/sha
This commit moves the existing linkcmds.base to linkcmds.base.in
in order to make it configurable by autotools.
---
bsps/riscv/shared/start/{linkcmds.base => linkcmds.base.in} | 0
c/src/lib/libbsp/riscv/riscv/Makefile.am| 2 +-
c/src/lib/libbsp/riscv/riscv/configure.ac
---
bsps/riscv/riscv/config/rv64imafdc_clang.cfg | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 bsps/riscv/riscv/config/rv64imafdc_clang.cfg
diff --git a/bsps/riscv/riscv/config/rv64imafdc_clang.cfg
b/bsps/riscv/riscv/config/rv64imafdc_clang.cfg
new file mode 100644
in
commit message, the hash has the fix
https://github.com/riscv/riscv-isa-sim/commit/fb27391bf65ed867b62ef40b726a21ac839fa37a
> On Tue, Oct 22, 2019, 9:56 AM Hesham Almatary
> wrote:
>>
>> Latest Spike integrated fesvr in its source directory, so there
>> is no separate fesvr
Latest Spike integrated fesvr in its source directory, so there
is no separate fesvr anymore.
Also use a revision of Spike that fixes the file permissions
when getting installed.
---
bare/config/devel/spike-1.1.0.cfg | 5 +
source-builder/config/spike-1-1.cfg | 19 +--
2 fi
Yeah happy for it to go through. Thanks for the patch
On Tue, 22 Oct 2019 at 08:26, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello Pragnesh,
>
> thanks for the reminder and sorry for the review delay. Overall, the
> patch looks good from my point of view. Would you mind chan
error persists with that patch?
> --joel
>
> On Thu, Oct 10, 2019 at 7:57 AM Hesham Almatary
> wrote:
>>
>> ---
>> MAINTAINERS | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 68137a80d9..f00
Latest Spike integrated fesvr in its source directory, so there
is no separate fesvr anymore.
---
bare/config/devel/spike-1.1.0.cfg | 5 +
source-builder/config/spike-1-1.cfg | 19 +--
2 files changed, 6 insertions(+), 18 deletions(-)
diff --git a/bare/config/devel/spike-1.
On Wed, 9 Oct 2019 at 12:54, Pragnesh Patel wrote:
>
> Added support for Sifive Freedom FE310 soc on Arty A7 FPGA board.
> Update #3785.
>
> Signed-off-by: Pragnesh Patel
> ---
>
> Changes in v4:
> - Revert fdt32_t *val to const in riscv_clock_get_timebase_frequency()
> - make RISCV_ENABLE_FR
pp...@pikron.com
Christian Mauderer christian.maude...@embedded-brains.de
+Hesham Almataryheshamelmat...@gmail.com
Localized Write Permission
==
--
2.17.1
___
devel mailing list
devel@rtems.org
http
Hi Pragnesh,
That's a so much better refined patch, thanks! Please find my minor
comments inlined below.
After the patch gets merged, could you please add a new section about
that BSP to the RISC-V chapter doc here [1]?
[1] https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
On Fri
On Wed, 11 Sep 2019 at 15:12, Hesham Almatary wrote:
>
> On Wed, 11 Sep 2019 at 14:07, Pragnesh Patel
> wrote:
> >
> > Fredom E310 Arty has a support for FDT but right now, u-boot (or any
> > bootloader) will not copy FDT address into CPU register (a1 for RISCV)
&g
On Wed, 11 Sep 2019 at 14:07, Pragnesh Patel wrote:
>
> Fredom E310 Arty has a support for FDT but right now, u-boot (or any
> bootloader) will not copy FDT address into CPU register (a1 for RISCV)
> instead we have given FDT address manually as shown below:
>
On FPGA/hardware, a bootrom (part of
Hi Pragnesh,
Thanks for the v2 update. I guess our question/comment on the previous
v1 patch was about the addition of bsps/riscv/frdme310arty/ directory
at all. That is, you might be able to just use bsps/riscv/riscv
already. Are there any significant changes that prevent you from just
using "bs
I have a pending partial review which seconds Sebastian's opinion.
Most notably, the clock, btimer drivers code duplicate most of the
existing riscv drivers. It might be easier to just use the existing
generic riscv BSP ones, and if they lack any features, you can fix
that. Also, all of the csr_*()
>> *** TEST TOOLS: 9.1.0 20190503 (RTEMS 5, RSB
>> >> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
>> >>
>> >> Divide by zero and confirm fetestexcept().
>> >>
>> >> 8
>> >> 0
>> >> 1
>> >>
>> &
On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta wrote:
>
> Configure command I used to build BSP:
> ==
> $ /home/varodek/development/rtems/kernel/rtems/configure
> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
> --target=riscv-rtems5
101 - 200 of 511 matches
Mail list logo