Re: RISC-V tool chain

2018-05-28 Thread Sebastian Huber
A second version of the GCC patch is attached. It has this problem: https://gcc.gnu.org/ml/gcc/2018-05/msg00259.html -- 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...@

Re: RISC-V tool chain

2018-05-28 Thread Hesham Almatary
On Mon, May 28, 2018 at 10:57 AM, Sebastian Huber wrote: > On 28/05/18 11:51, Hesham Almatary wrote: >>> >>> I try currently a different direction. I use custom multilibs and changed >>> the default cmodel to medany for the 64-bit variants. See attached patch. >>> I wonder if that issue/solution i

Re: [PATCH] bsps/riscv: Rename riscv_generic to riscv32_generic and add compiler flags

2018-05-28 Thread Hesham Almatary
On Mon, May 28, 2018 at 12:01 PM, Sebastian Huber wrote: > On 28/05/18 12:02, Hesham Almatary wrote: >> >> On Mon, May 28, 2018 at 10:55 AM, Sebastian Huber >> wrote: >>> >>> On 28/05/18 11:47, Hesham Almatary wrote: This makes it explicitly 32-bit. Compiler flags are needed if built wi

[PATCH] bsps/riscv_generic: Rename and add riscv BSPs to match supported RISC-V ISA variants

2018-05-28 Thread Hesham Almatary
--- bsps/riscv/riscv_generic/config/riscv64_generic.cfg | 7 --- bsps/riscv/riscv_generic/config/riscv_generic.cfg | 7 --- bsps/riscv/riscv_generic/config/rv32i.cfg | 7 +++ bsps/riscv/riscv_generic/config/rv32iac.cfg | 7 +++ bsps/riscv/riscv_generic/config/rv

Re: [PATCH] bsps/riscv: Rename riscv_generic to riscv32_generic and add compiler flags

2018-05-28 Thread Sebastian Huber
On 28/05/18 12:02, Hesham Almatary wrote: On Mon, May 28, 2018 at 10:55 AM, Sebastian Huber wrote: On 28/05/18 11:47, Hesham Almatary wrote: This makes it explicitly 32-bit. Compiler flags are needed if built with a non riscv32-* toolchain (e.g. riscv64-* with multilib). I would like to rena

Re: [PATCH] bsps/riscv: Rename riscv_generic to riscv32_generic and add compiler flags

2018-05-28 Thread Hesham Almatary
On Mon, May 28, 2018 at 10:55 AM, Sebastian Huber wrote: > On 28/05/18 11:47, Hesham Almatary wrote: >> >> This makes it explicitly 32-bit. Compiler flags are needed if built with >> a non riscv32-* toolchain (e.g. riscv64-* with multilib). > > > I would like to rename the BSPs to use the ISA name

Re: RISC-V tool chain

2018-05-28 Thread Sebastian Huber
On 28/05/18 11:51, Hesham Almatary wrote: I try currently a different direction. I use custom multilibs and changed the default cmodel to medany for the 64-bit variants. See attached patch. Thanks for sharing the patch, this solution is neat. We can get rid of the arch alias hack. No, we have

Re: [PATCH] bsps/riscv: Rename riscv_generic to riscv32_generic and add compiler flags

2018-05-28 Thread Hesham Almatary
This should allow building riscv32_generic with riscv64-rtems* toolchain (or just riscv-rtems*). I tested that. On Mon, May 28, 2018 at 10:47 AM, Hesham Almatary wrote: > This makes it explicitly 32-bit. Compiler flags are needed if built with > a non riscv32-* toolchain (e.g. riscv64-* with mult

Re: [PATCH] bsps/riscv: Rename riscv_generic to riscv32_generic and add compiler flags

2018-05-28 Thread Sebastian Huber
On 28/05/18 11:47, Hesham Almatary wrote: This makes it explicitly 32-bit. Compiler flags are needed if built with a non riscv32-* toolchain (e.g. riscv64-* with multilib). I would like to rename the BSPs to use the ISA name, e.g. rv32imac, rv64imafdc, etc. I also would like to add support for

Re: RISC-V tool chain

2018-05-28 Thread Hesham Almatary
On Mon, May 28, 2018 at 10:38 AM, Sebastian Huber wrote: > On 28/05/18 11:14, Hesham Almatary wrote: >> >> On Mon, May 28, 2018 at 6:23 AM, Sebastian Huber >> wrote: >>> >>> Hello, >>> >>> we currently have a riscv32-rtems* and riscv64-rtems* tool chain. >>> However, >>> the RISC-V GCC is a bi-a

[PATCH] bsps/riscv: Rename riscv_generic to riscv32_generic and add compiler flags

2018-05-28 Thread Hesham Almatary
This makes it explicitly 32-bit. Compiler flags are needed if built with a non riscv32-* toolchain (e.g. riscv64-* with multilib). --- bsps/riscv/riscv_generic/config/riscv32_generic.cfg | 7 +++ bsps/riscv/riscv_generic/config/riscv_generic.cfg | 7 --- 2 files changed, 7 insertions(+),

Re: RISC-V tool chain

2018-05-28 Thread Sebastian Huber
On 28/05/18 11:14, Hesham Almatary wrote: On Mon, May 28, 2018 at 6:23 AM, Sebastian Huber wrote: Hello, we currently have a riscv32-rtems* and riscv64-rtems* tool chain. However, the RISC-V GCC is a bi-arch compiler, e.g. we have riscv32-rtems5-gcc --print-multi-lib .; rv32i/ilp32;@march=rv

Re: RISC-V tool chain

2018-05-28 Thread Hesham Almatary
On Mon, May 28, 2018 at 6:23 AM, Sebastian Huber wrote: > Hello, > > we currently have a riscv32-rtems* and riscv64-rtems* tool chain. However, > the RISC-V GCC is a bi-arch compiler, e.g. we have > > riscv32-rtems5-gcc --print-multi-lib > .; > rv32i/ilp32;@march=rv32i@mabi=ilp32 > rv32im/ilp32;@m

Re: RISC-V tool chain

2018-05-28 Thread Hesham Almatary
On Mon, May 28, 2018 at 6:23 AM, Sebastian Huber wrote: > Hello, > > we currently have a riscv32-rtems* and riscv64-rtems* tool chain. However, > the RISC-V GCC is a bi-arch compiler, e.g. we have > > riscv32-rtems5-gcc --print-multi-lib > .; > rv32i/ilp32;@march=rv32i@mabi=ilp32 > rv32im/ilp32;@m

Re: RISC-V BSP memory map

2018-05-28 Thread Sebastian Huber
On 28/05/18 10:48, Hesham Almatary wrote: The FE310-G000 has the ROM at 0x2000_ and RAM (DTIM) at 0x8000_. The FU540-C000 (and Qemu "virt") has the ROM at 0x2000_ and RAM (DDR) at 0x8000_. So, why is the memory at 0x1000_ and not 0x8000_? That's basically a hack. The r

Re: RISC-V BSP memory map

2018-05-28 Thread Hesham Almatary
Hi Sebastian, On Mon, May 28, 2018 at 6:39 AM, Sebastian Huber wrote: > Hello, > > on which board do the RISC-V BSPs run? The memory is located at 0x1000_. > None so far. I only ran in on Spike (RISC-V simulator). At the time of the port (2015), there were no hardware or boards for RISC-V

question about rtc command

2018-05-28 Thread jameszxj
hi all, rtc command return the current time of day, it seems unreasonable. I think it should return the time of real time clock. Any other reasons to do so?___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel