Re: CVA6 RISC-V support

Hello, Thanks for sending out the patches. Could you please send them as emails instead of attachments? e.g., using git send-email [1]. That'll be easier to review and comment on. [1] https://docs.rtems.org/branches/master/user/support/contrib.html Regards, Hesham On Tue, 1 Aug 2023 at 16:53,

Re: [PATCH] bsps/aarch64: Enable MMU during remaps

On Mon, 17 Apr 2023 at 23:10, Kinsey Moore wrote: > > The MMU must be enabled during mapping changes and TLB invalidations. > When this is not the case, TLB updates do not occur correctly in all > cases. This is especially apparent when changing a block entry to a > table entry when remapping

Re: [PATCH v2] docs/user: add docs for riscv/kendrytek210 BSP variant

ps://github.com/alanc98/rki2/tree/rtems6 >>> >>> Alan >>> >>> >>> On Sat, Apr 1, 2023 at 6:13 PM Alan Cudmore wrote: >>>> >>>> Interesting - I get the same error when I run ticker on renode now. I just >>>> tried

Re: [PATCH v2] docs/user: add docs for riscv/kendrytek210 BSP variant

an Cudmore wrote: > > Hi Hesham, > I applied your suggestions and sent a v3 patch. > Thanks for the review, > Alan > > > On Sat, Apr 1, 2023 at 1:43 PM Hesham Almatary > wrote: >> >> On Fri, 31 Mar 2023 at 17:15, Alan Cudmore wrote: >> > >> &g

Re: [PATCH v2] docs/user: add docs for riscv/kendrytek210 BSP variant

On Fri, 31 Mar 2023 at 17:15, Alan Cudmore wrote: > > This patch adds the documentation for building and running RTEMS on the > Kendryte K210 > RISC-V SoC. The generic riscv introducion was re-arranged to list the > multilib variants > then the specific hardware targets. In addition a couple of

Re: [PATCH rtems-tools] rtems-bsps-riscv.ini: Update list to drop medany and add BSPs

On Tue, 14 Mar 2023 at 15:03, Joel Sherrill wrote: > > > > On Tue, Mar 14, 2023 at 9:23 AM Hesham Almatary > wrote: >> >> On Tue, 14 Mar 2023 at 14:14, Joel Sherrill wrote: >> > >> > --- >> > config/rtems-bsps-riscv.ini | 16 +++---

Re: [PATCH rtems-tools] rtems-bsps-riscv.ini: Update list to drop medany and add BSPs

On Tue, 14 Mar 2023 at 14:14, Joel Sherrill wrote: > > --- > config/rtems-bsps-riscv.ini | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/config/rtems-bsps-riscv.ini b/config/rtems-bsps-riscv.ini > index 804245e..816675f 100644 > ---

Re: [PATCH] riscv: Update RISC-V BSPs

On Wed, 22 Feb 2023 at 20:48, Sebastian Huber wrote: > > On 22.02.23 16:14, Hesham Almatary wrote: > > * Remove BSPs with medany name in them (See #4775). > > RV64 BSPs are now all medany by default. > > Do we still need the non-medany 64-bit multilibs in GCC? I plan

[PATCH] riscv: Update RISC-V BSPs

* Only use BSPs supported by GCC's multilibs. This removes rv32imafdc * Remove BSPs with medany name in them (See #4775). RV64 BSPs are now all medany by default. --- config/rtems-bsps-riscv.ini | 5 ++--- config/rtems-bsps-tiers.ini | 5 ++--- 2 files changed, 4 insertions(+), 6 deletions(-)

Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0

accessible. At the moment > things are just crowbarred into the build system to make it work. > > Coming back to the patch: If there are no objections I would like to push the > commit for llvm11. > Chances are that further updates are to come as I progress. > > Best regards,

Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0

On Wed, 15 Feb 2023 at 09:22, wrote: > > > > > -Original Message- > > From: Hesham Almatary > > Sent: Montag, 13. Februar 2023 16:19 > > To: Sommer, Jan > > Cc: j...@rtems.org; devel@rtems.org > > Subject: Re: [PATCH v1 0/1] Update rtems-

Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0

On Mon, 13 Feb 2023 at 12:12, wrote: > > > -Original Message- > > From: Joel Sherrill > > Sent: Freitag, 10. Februar 2023 15:21 > > To: Sommer, Jan > > Cc: devel@rtems.org > > Subject: Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0 > > > > > > > > On Fri, Feb 10, 2023 at 3:16 AM

Re: Risc-v failures Fwd: [rtems-bsp-builder] 2023-02-12 05:13:18: Profile(s): everything

Hello Joel, There shouldn't be any BSP with "medany" name in it. Where's the build script? I tried to fix your build in the cron script [1] but not sure if you use "medany" anywhere else. [1] https://github.com/joelsherrill/rtems-cron-helpers/pulls On Sun, 12 Feb 2023 at 18:12, Joel Sherrill

Re: [PATCH 2/2] RISC-V: Test rv32i and rv32imafdc on QEMU

This needs to be merged for the tests to pass. On Mon, 9 Jan 2023 at 18:28, Hesham Almatary wrote: > > Is this patchset fine to merge? > > On Fri, 23 Dec 2022 at 09:25, wrote: > > > > From: Hesham Almatary > > > > Updates #4775 > > --- > >

Re: [PATCH] risc-v: Resurrect RISCV_ENABLE_HTIF_SUPPORT

LGTM. We also need to update the docs accordingly. On Wed, 11 Jan 2023 at 07:45, Sebastian Huber wrote: > > Low-end configurations may want to have the HTIF support removed. > Enable the option by default. Fix formatting. Fix node validity > checks. > > Updates #4779. > --- >

Re: [PATCH 2/2] RISC-V: Test rv32i and rv32imafdc on QEMU

Is this patchset fine to merge? On Fri, 23 Dec 2022 at 09:25, wrote: > > From: Hesham Almatary > > Updates #4775 > --- > tester/rtems/testing/bsps/rv32i.ini | 37 > tester/rtems/testing/bsps/rv32imafdc.ini | 37 &

Re: [PATCH 1/3] Docs: RISC-V Update rv64* BSPs to medany and 0x80000000 start address

Ping (as this was sent over holidays). On Fri, 23 Dec 2022 at 09:48, wrote: > > From: Hesham Almatary > > Closes #4775 > --- > user/bsps/bsps-riscv.rst | 27 --- > 1 file changed, 12 insertions(+), 15 deletions(-) > > diff --git a/user/bsps

Re: [PATCH 1/2] spec/build/riscv: Default all BSPs to medany cmodel

On Mon, 19 Dec 2022 at 16:29, Sebastian Huber wrote: > > Hello Hesham, > > On 18/12/2022 15:27, heshamelmat...@gmail.com wrote: > > From: Hesham Almatary > > > > Currently generic RISC-V BSPs (riscv/riscv) that start with rv* and not > > rv*_medany will

Re: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader

> Thanks, > > > > Alan > > > > From: heshamelmat...@gmail.com > > Sent: Tuesday, October 25, 2022 1:48 PM > > To: devel@rtems.org > > Subject: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance > > on a boot loader > > > &

Re: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader

ctober 25, 2022 1:48 PM > To: devel@rtems.org > Subject: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance > on a boot loader > > > > From: Hesham Almatary > > > > The BSP is capable of initialising the hardware being the first software > > that ta

Re: rtems-libbsd support RISC-V or not

I tested building a RISC-V BSP (rv64imafdc_medany) for QEMU today. Things build out the box. I also tried to run the tests and got the following results: Passed:31 Failed: 4 User Input:21 Expected Fail: 0 Indeterminate: 0 Benchmark: 0 Timeout:0 Test too long: 0

Re: [PATCH v6 0/1] NOEL-V BSP

Looks good. Thanks! On Wed, 31 Aug 2022 at 09:25, Daniel Cederman wrote: > > v6 > Change family entry to noel in all BSP build specs > Synchronize irq.h and riscv.h with versions in riscv BSP > > Martin Aberg (1): > bsp/riscv: Add NOEL-V BSP > > bsps/include/bsp/fatal.h |

Re: [PATCH v2 1/1] bsp/riscv: Work area size based on /memory node in fdt

On Fri, 19 Aug 2022 at 13:36, Daniel Cederman wrote: > On 2022-08-19 11:16, Hesham Almatary wrote: > > On Thu, 18 Aug 2022 at 13:55, Daniel Cederman > wrote: > >> I missed your comment, but have made the change now. Are there any > instructions on how to run the RISCV BS

Re: [PATCH v2 1/1] bsp/riscv: Work area size based on /memory node in fdt

AFAIR, you need to run the "medany" RISC-V variants for QEMU, I'd use rtems-tester. No special QEMU version is needed. > On 2022-08-18 10:24, Hesham Almatary wrote: > > All good, I'd just replace the "end == 0" with "end == NULL" as per my > comment above

Re: [PATCH v2 1/1] bsp/riscv: Work area size based on /memory node in fdt

All good, I'd just replace the "end == 0" with "end == NULL" as per my comment above. Also please test on other RISC-V QEMU platforms to make sure nothing got broken. On Wed, 17 Aug 2022 at 14:10, Joel Sherrill wrote: > > I'm ok with this if Hesham acks as well. > > --joel > > On Wed, Aug 17,

Re: [PATCH] bsp/riscv: Work area size based on /memory node in fdt

Thanks for the patch. LGTM. I wonder if we can also reuse that for the generic shared RISC-V BSP (e.g., bsps/riscv/riscv) instead of just NOEL? On Wed, 17 Aug 2022 at 09:58, Daniel Cederman wrote: > Uses the first entry in the /memory node to determine the end of the > work area. Falls back on

Re: [PATCH v4 1/2] bsp/riscv: Work area size based on stack pointer

On Mon, 15 Aug 2022 at 15:35, Daniel Cederman wrote: > > On 2022-08-15 15:43, Hesham Almatary wrote: > > On Mon, 15 Aug 2022 at 08:16, Daniel Cederman wrote: > >> From: Martin Aberg > >> > >> Remember the initial stack pointer in start.S. It can lat

Re: [PATCH v4 1/2] bsp/riscv: Work area size based on stack pointer

On Mon, 15 Aug 2022 at 08:16, Daniel Cederman wrote: > > From: Martin Aberg > > Remember the initial stack pointer in start.S. It can later be used to > determine top of RAM. > --- > bsps/riscv/include/bsp/start.h| 67 >

Re: [PATCH RSB] Update to dtc 1.6.1

On Fri, 29 Oct 2021 at 01:37, Joel Sherrill wrote: > > On Thu, Oct 28, 2021, 6:25 PM Chris Johns wrote: > > > On 29/10/21 6:26 am, Joel Sherrill wrote: > > > On Thu, Oct 28, 2021 at 12:20 PM Hesham Almatary > > > wrote: > > >> > >

Re: [PATCH RSB] Update to dtc 1.6.1

Does RISC-V need that too? On Thu, 28 Oct 2021 at 16:41, Alex White wrote: > This bumps the dtc version from 1.6.0 to 1.6.1. Building 1.6.0 on > FreeBSD 13 was unsuccessful, but 1.6.1 appears to build fine. > --- > bare/config/devel/dtc-1.6.1-1.cfg | 18 ++ >

Re: [PATCH 3/3] microblaze: Rework for RTEMS 6

On Sat, 2 Oct 2021 at 02:44, Chris Johns wrote: > > On 1/10/21 3:43 pm, Alex White wrote: > > bsps/microblaze/include/common/xil_types.h| 197 +++ > > bsps/microblaze/include/dev/serial/uartlite.h | 62 + > > .../include/dev/serial/uartlite_l.h | 323 + > >

Re: Building llvm toolchain for RTEMS

Hello Jan, Unlike GCC, LLVM/Clang only gives you one toolchain for all backend architectures (depending on how you configured it). You'll also need to tell LLVM/Clang where to find the sysroot to pick newlib and builtins headers/libs. GCC does that automatically for you, but LLVM/Clang does not.

Re: [PATCH v2] Add CoreMark Benchmark

Submitting that again based on Joel's request. I created a ticket [1] for future Make support as it only builds with waf. [1] https://devel.rtems.org/ticket/4441#ticket On Wed, 26 May 2021 at 11:23, Hesham Almatary wrote: > > CoreMark's primary goals are simplicity and providing a

[PATCH v2] Add CoreMark Benchmark

wscript b/benchmarks/coremark/wscript new file mode 100644 index 000..2ec5f1e --- /dev/null +++ b/benchmarks/coremark/wscript @@ -0,0 +1,50 @@ +#- +# SPDX-License-Identifier: BSD-2-Clause +# +# Copyright (c) 2021 Hesham Almatary +# +# This software was developed by SRI International and the Univer

[PATCH] Add CoreMark Benchmark

/benchmarks/coremark/wscript b/benchmarks/coremark/wscript new file mode 100644 index 000..2ec5f1e --- /dev/null +++ b/benchmarks/coremark/wscript @@ -0,0 +1,50 @@ +#- +# SPDX-License-Identifier: BSD-2-Clause +# +# Copyright (c) 2021 Hesham Almatary +# +# This software was developed by SRI Internationa

Re: [PATCH] riscv/console: console-config.c update

Hello Somesh, This patch will break other existing BSPs that don't have "stdout-path" (in your case serial@x) node part of "/soc" node. You can either 1) Modify your DTS to have /serial node outside /soc, or 2) Add a new config for your BSP such as RISCV_ENABLE_FRDME310ARTY_SUPPORT and use it

Re: [PATCH] rtems-examples: Add CoreMark Benchmark

Hello Damien, Glad to know you have an interest in it. Yes, we needed to add Make support for it, I just didn't get to work on that yet. Do you need to exclusively use Make and not waf though? On Fri, 30 Apr 2021 at 16:50, BAILLIEZ Damien wrote: > > Hi all, > > > > I’ve seen in the Archives

Re: [PATCH] riscv/start: Startup sequence update.

On Fri, 30 Apr 2021 at 14:22, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 29/04/2021 20:53, Sebastian Huber wrote: > > > On 29/04/2021 20:18, Hesham Almatary wrote: > > > >>>> I would place the device tree in a noinit section. > >

Re: [PATCH] riscv/console: Updated the console-config.c file

On Fri, 30 Apr 2021 at 04:44, somesh deshmukh wrote: > > > On Thu, Apr 29, 2021 at 10:59 PM Hesham Almatary < > hesham.almat...@cl.cam.ac.uk> wrote: > >> On Wed, 28 Apr 2021 at 15:23, Somesh Deshmukh >> wrote: >> > >> > - Parsing th

Re: [PATCH] riscv/start: Startup sequence update.

On Thu, 29 Apr 2021 at 20:07, Gedare Bloom wrote: > > On Thu, Apr 29, 2021 at 11:53 AM Sebastian Huber > wrote: > > > > > > On 28/04/2021 15:55, Somesh Deshmukh wrote: > > > +/* Clear .bss */ > > > +LADDRa0, bsp_section_bss_begin > > > +li a1, 0 > > > +LADDRa2,

Re: [PATCH] riscv/start: Startup sequence update.

On Wed, 28 Apr 2021 at 15:55, Somesh Deshmukh wrote: > > - The current startup sequence performs the call to the bsp_fdt_copy() and > then > performs memset to the BSS region. In bsp_fdt_copy(), RTEMS allocates > memory for bsp_fdt_blob into BSS region which is yet to initialize. With >

Re: [PATCH] riscv/console: Updated the console-config.c file

On Wed, 28 Apr 2021 at 15:23, Somesh Deshmukh wrote: > > - Parsing the sub-node should be available generic not specific to Freedom > Arty310 board. If we remove the Freedom Arty macro now, it will lose > backward compatibility.The proposed change will retain the backward > compatibility

Re: RTEMS on PolarFire SoC ICICLE Kit FPGA

On Sun, 25 Apr 2021 at 21:04, somesh deshmukh wrote: > > Hi Hesham, > > Comments added below and please find the attached device tree source file. > > Regards, > Somesh > > On Sun, Apr 25, 2021 at 12:34 AM Hesham Almatary > wrote: >> >> Hello Somesh,

Re: RTEMS on PolarFire SoC ICICLE Kit FPGA

Hello Somesh, On Sat, 24 Apr 2021 at 20:52, somesh deshmukh wrote: > > Hi, > > The diff between the changed files is mentioned below. The default riscv > clock driver is recently updated and it includes the changes I was proposing. > > --- /rtems/bsps/riscv/riscv/console/console-config.c

Re: [PATCH] rld-cc: Add -target to recognised cflags

Ping On Wed, 24 Mar 2021 at 09:57, Hesham Almatary wrote: > -target *-*-* flag is necessary for LLVM/Clang while cross-compiling > --- > rtemstoolkit/rld-cc.cpp | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/rtemstoolkit/rld-cc.cpp b/rtemstoolkit/rld-cc.cpp > i

Re: GSoC project: Memory protection (Ticket no: 2904)

mation about the RISC-V MMU. I want to know what > work has to be done in improving MMU in RISC-V and if it can be a GSoC > project. It would be great if you could provide the details regarding this. > > Thanks and regards, > Rajiv > > On Wed, 24 Mar 2021 at 00:03, Hesham Almatar

[PATCH] rld-cc: Add -target to recognised cflags

-target *-*-* flag is necessary for LLVM/Clang while cross-compiling --- rtemstoolkit/rld-cc.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/rtemstoolkit/rld-cc.cpp b/rtemstoolkit/rld-cc.cpp index bb03ff6..b424214 100644 --- a/rtemstoolkit/rld-cc.cpp +++ b/rtemstoolkit/rld-cc.cpp @@

Re: GSoC project: Memory protection (Ticket no: 2904)

On Tue, 23 Mar 2021 at 17:14, Gedare Bloom wrote: > > CC: Hesham > CC: devel > > On Tue, Mar 23, 2021 at 6:34 AM Rajiv Vaidyanathan > wrote: > > > > Dear Gedare, > > > > Thank you for providing information regarding the project. For risk-v MMU > > support, will I require to have hardware? > > >

Re: [PATCH] rtems-examples: Add CoreMark Benchmark

; > This is fine with me as-is, I just want to know if we can keep it > supporting both build systems. > > On Sat, Mar 13, 2021 at 12:50 AM Hesham Almatary > wrote: > > > > CoreMark's primary goals are simplicity and providing a method for > > testing on

Re: Regarding gsoc project 3860

Hello Ayushman and Ida, Usually, if multiple students really want to work on a particular project (and can't/don't want to choose another), there can be multiple proposals for the same project and we choose the best one. Sometimes a project can be split up between two students to work on to

Re: [PATCH] rtems-examples: Add CoreMark Benchmark

541482bf3e6ef7f5c69f5be76b14537b60833d0 >> diff --git a/benchmarks/coremark/wscript b/benchmarks/coremark/wscript >> new file mode 100644 >> index 000..2ec5f1e >> --- /dev/null >> +++ b/benchmarks/coremark/wscript >> @@ -0,0 +1,50 @@ >> +#- >> +# SPD

[PATCH] rtems-examples: Add CoreMark Benchmark

/benchmarks/coremark/wscript b/benchmarks/coremark/wscript new file mode 100644 index 000..2ec5f1e --- /dev/null +++ b/benchmarks/coremark/wscript @@ -0,0 +1,50 @@ +#- +# SPDX-License-Identifier: BSD-2-Clause +# +# Copyright (c) 2021 Hesham Almatary +# +# This software was developed by SRI Internationa

Re: sifive risc-v hifive unleashed bsp (qemu)

osed. Deciding a ticket is dead is good. >> :) >> >> >> https://devel.rtems.org/query?status=accepted=assigned=new=reopened=~Small=id=summary=status=owner=type=priority=milestone=priority >> >> Looking at Coverity is a quick way to find a small task. Some

Re: sifive risc-v hifive unleashed bsp (qemu)

On Fri, 12 Feb 2021 at 11:24, Sanskar Khandelwal wrote: > > Hello joel, > > 1. #4162 : sifive risc-v hifive unleashed bsp (qemu) > As you mentioned this a good project i thought to search more about this > project I learned a lot while doing so but I still don't understand what is > the goal of

Re: [PATCH 3/4 v2] bsp/riscv: work area size based on stack pointer

On Fri, 12 Feb 2021 at 10:50, Daniel Hellstrom wrote: > > From: Martin Aberg > > Remember the initial stack pointer in start.S. It can later be used to > determine top of RAM. > --- > bsps/riscv/include/bsp/start.h | 65 > ++ >

Re: [PATCH 3/4] bsp/riscv: work area size based on stack pointer

On Tue, 9 Feb 2021 at 07:11, Sebastian Huber wrote: > > On 08/02/2021 20:44, Daniel Hellstrom wrote: > > > + > > + .section.data, "aw" > > + .align 3 > > + > > + .globl bsp_sp_at_entry > > + .type bsp_sp_at_entry, @object > > + .size bsp_sp_at_entry, 8 > >

Re: Status of clang-llvm builds? Related to powerpc-spe.

On Fri, 22 Jan 2021 at 21:30, wrote: > > Actually, replying to myself: > > I bet the context-switching code is broken for platforms that use the SPE via > a Freescale library. That's something I'll need to look at. > > > On Jan 22, 2021, at 14:26 , Peter Dufault wrote: > > > > Signed PGP part

Re: RTEMS booting on PolarFire SoC FPGA

U, etc. So even if you disable BSP_START_COPY_FDT_FROM_U_BOOT, this will get you a bit far ahead but will still fail during the FDT probing done later. > > Thanks and Regards, > Somesh > > On Tue, Jan 5, 2021 at 5:53 PM Hesham Almatary > wrote: >> >> I don't see why the "auipc" wou

Re: RTEMS booting on PolarFire SoC FPGA

I don't see why the "auipc" would fail. Are you sure that's the faulting instruction? Can you read mcause/mepc from your debugger after it hangs? How/where do you prepare the FDT and pass it to RTEMS? bsp_fdt_copy expects the bootloader to pass the HARTID in a0, and the FDT pointer in a1. On

Re: libdl: How to debug dl object with GDB

Thanks, Chris for the detailed reply. On Thu, 19 Nov 2020 at 22:56, Chris Johns wrote: > > On 19/11/20 5:33 pm, Hesham Almatary wrote: > > Thanks for the info, Chris. > > > > On Wed, 18 Nov 2020 at 02:43, Chris Johns wrote: > >> On 17/11/20 10:43 pm, H

Re: libdl: How to debug dl object with GDB

Thanks for the info, Chris. On Wed, 18 Nov 2020 at 02:43, Chris Johns wrote: > > > > On 17/11/20 10:43 pm, Hesham Almatary wrote: > > Hello, > > > > I am trying to debug a dynamically loaded ELF object with GDB: My setup is: > > rtems-riscv64: > > GDB:

libdl: How to debug dl object with GDB

Hello, I am trying to debug a dynamically loaded ELF object with GDB: My setup is: rtems-riscv64: GDB: GNU gdb (GDB) 10.0.50.20200904-git (build with RSB/rtems6) Host: Ubuntu 20.04.1 LTS GDB doesn't seem to notice when I dlopen an object (which gets loaded, linked and run fine). Any instructions

Re: [AArch64] Announcing the Morello branch in binutils-gdb

Hello Joel, On Thu, 29 Oct 2020 at 15:02, Joel Sherrill wrote: > > Morello is a prototype implementation of CHERI. Binutils will remain on a > branch and the compiler support is LLVM. > > Hesham.. any thoughts? > We are very excited about the Morello releases. It should get more people to try

Re: [PATCH] score/aarch64: Size saved SP register for ABI

On Thu, 22 Oct 2020 at 20:07, Kinsey Moore wrote: > This ensures that the saved SP register is sized appropriately depending > on the chosen ABI and prevents a warning in the libmisc stack checker. > --- > cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 5 - > 1 file changed, 4

[PATCH] riscv: Make sifive_test finisher 4 bytes

QEMU is now stricter with MMIO sizes and accesses. uintptr_t on RV64 is 8 bytes and generates an sd instruction that Store/AMO faults because sifive_test MMIO expects 4 bytes accesses. --- bsps/riscv/riscv/start/bsp_fatal_halt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] bsps/riscv: Use far jump to boot_card()

Thanks, Sebastian, LGTM. On Mon, 14 Sep 2020 at 14:01, Joel Sherrill wrote: > > Looks good. Reasonable and safer. > > On Mon, Sep 14, 2020 at 12:10 AM Sebastian Huber > wrote: >> >> Use a far jump to avoid errors like this: >> >> relocation truncated to fit: R_RISCV_JAL against symbol

[PATCH] rsb: Fix the documentation URL

--- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/README index 34350c8..0a9ae72 100644 --- a/README +++ b/README @@ -20,7 +20,7 @@ The project is part of the RTEMS Project. The project's websites are: https://git.rtems.org/rtems-source-builder.git/

Re: dl06 fails to build for RISC-V (griscv bsp)

On Mon, 7 Sep 2020 at 09:01, Jiri Gaisler wrote: > > > On 9/7/20 10:44 AM, Hesham Almatary wrote: > > I have only made sure rap builds when I added libdl support for > > RISC-V. But I haven't tested it on run-time, only ELF objects. It's > > likely to have been failing

Re: dl06 fails to build for RISC-V (griscv bsp)

that by passing -mno-relax On Sun, 6 Sep 2020 at 19:50, Jiri Gaisler wrote: > > I re-applied your patch and dl06 builds again, but the dl06.exe program > fails. I have updated the ticket: > > https://devel.rtems.org/ticket/4069#no2 > > > On 9/6/20 10:12 AM, Hesham Almatary wr

Re: More RISC-V Failures on Master

I sent a patch to fix that earlier but it didn’t make it upstream. Please feel free to push it https://lists.rtems.org/pipermail/devel/2020-May/059773.html On Sun, Sep 6, 2020 at 7:57 PM Joel Sherrill wrote: > Hi > > I see a duplicate symbol error on RISC-V BSPs which must not trip the >

Re: dl06 fails to build for RISC-V (griscv bsp)

Actually my commit is the latest, so please ignore the last reply. On Sun, 6 Sep 2020 at 09:18, Hesham Almatary wrote: > > I did a git blame, looks like that commit broke it [1]; my fix used to > "continue" if a sym belongs to section 0, but now it returns "false".

Re: dl06 fails to build for RISC-V (griscv bsp)

I did a git blame, looks like that commit broke it [1]; my fix used to "continue" if a sym belongs to section 0, but now it returns "false". [1] https://github.com/RTEMS/rtems-tools/commit/ec419a05ee52869a7d5b8712ea8e7a7d74fde096 On Sun, 6 Sep 2020 at 09:12, Hesham Almatar

Re: dl06 fails to build for RISC-V (griscv bsp)

That's the same as [1]. I've seen that error before and (thought I) fixed it [2], but not sure what has changed since then. [1] https://lists.rtems.org/pipermail/devel/2020-August/061717.html [2] https://github.com/RTEMS/rtems-tools/commit/e6e610d262940b7651157597b6b1406aa806b4d1 On Sun, 6 Sep

Re: Error in RISC-V Dynamic loading code

On Mon, 31 Aug 2020 at 15:05, Eshan Dhawan wrote: > > > >> On 31-Aug-2020, at 3:44 PM, Hesham Almatary > >> wrote: > > Hello Eshan, > > > > What rtems-tools version are you using? I remember I fixed that (or > > something similar) in this c

Re: Error in RISC-V Dynamic loading code

Hello Eshan, What rtems-tools version are you using? I remember I fixed that (or something similar) in this commit [1] [1] https://github.com/RTEMS/rtems-tools/commit/e6e610d262940b7651157597b6b1406aa806b4d1 On Sun, 30 Aug 2020 at 18:33, Eshan Dhawan wrote: > > Hello everyone, > While testing

Re: GSoC 2020 - Final project report

said, sorry to disturb you on a weekend but please take > >> > a look. > >> > > >> > On Sat, Aug 29, 2020 at 6:03 PM Utkarsh Rai > >> > wrote: > >> >> > >> >> > >> >> > >> >> On Sat, Aug 29, 202

Re: GSoC 2020 - Final project report

Hello Utkarsh, Thanks for the blog post. Are there any instructions on how can someone (maybe a future GSoC student or someone else interested) get your code tested (with test demos) and on which platform? A HOWTO guide/blogpost will be great. On Sat, 29 Aug 2020 at 00:51, Utkarsh Rai wrote: >

Re: Segmentation fault whie setting up translation table for small pages in ARMv7 MMU

On Sun, Jul 26, 2020 at 2:04 PM Utkarsh Rai wrote: > Hello, > I was facing issues while changing the memory entries for a section. The > thread can be viewed here > . The > error is most probably due to the fact that while I change

Re: GSoC: Correct placement and naming of memory protection APIs

We have already discussed and done that during my 2013 GSoC. Have a look at [1, 2] and their calls. [1] https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mmimpl.h [2]

Re: Setting up the TTBR0 and TTBR1 register for thread stack protection in ARMv7-A MMU

Hello Utkarsh, TTBR1 is there primarily for UNIX-like kernels to be re-mapped at very high addresses and user space can use TTBR0. In the case of RTEMS, we don't have that user vs kernel separation. Furthermore, using TTBR1 won't allow us to do 1:1 fixed mappings. Could you give more details why

Re: [PATCH] riscv: Mark htif_console_handler in htif.h as extern

On Mon, 18 May 2020 at 06:10, Gedare Bloom wrote: > > you can push this one. I don't know if there are others? Thanks! Yeah, just one more here [1] but it's not vital/used yet. [1] https://lists.rtems.org/pipermail/devel/2020-May/059772.html > > On Sun, May 17, 2020 at 7:06 PM Hes

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

d, the hardware will make sure it gets the correct entry (by doing a HW page-table walk). On Wed, 20 May 2020 at 11:05, Utkarsh Rai wrote: > > > > > On Wed, May 20, 2020 at 7:40 AM Hesham Almatary > wrote: >> >> On Tue, 19 May 2020 at 14:00, Utkarsh Rai wrote: >

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

On Tue, 19 May 2020 at 14:00, Utkarsh Rai wrote: > > > > On Mon, May 18, 2020 at 8:38 PM Gedare Bloom wrote: >> >> On Mon, May 18, 2020 at 4:31 AM Utkarsh Rai wrote: >> > >> > >> > >> > >> > On Sat, May 16, 2020 at 9:16 PM Joel Sherrill wrote: >> >> >> >> >> >> >> >> On Sat, May 16, 2020 at

Re: [PATCH] riscv: Mark htif_console_handler in htif.h as extern

On Sun, 17 May 2020 at 23:45, Joel Sherrill wrote: > I hope you have committed these by now. :) > Not yet, was waiting for approval. Shall I wait for the release first? > > On Thu, May 7, 2020 at 3:14 PM wrote: > >> From: Hesham Almatary >> >> It is define

Re: Memory Protection project interface details (GSoC 2020)

On Tue, 12 May 2020 at 04:57, Gedare Bloom wrote: > > On Thu, May 7, 2020 at 9:59 PM Hesham Almatary > wrote: > > > > Hello Utkarsh, > > > > I'd suggest you don't spend too much efforts on setting up BBB > > hardware if you haven't already. Debugging on Q

Re: [PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

On Fri, 8 May 2020 at 05:42, Sebastian Huber wrote: > > On 07/05/2020 22:12, heshamelmat...@gmail.com wrote: > > > From: Hesham Almatary > > > > This commit fixes some run-time errors on 64-bit architectures (e.g., > > riscv64) > > in which the tcp head

Re: [PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

Chris > > On 8/5/20 6:12 am, heshamelmat...@gmail.com wrote: > > From: Hesham Almatary > > > > This commit fixes some run-time errors on 64-bit architectures (e.g., > > riscv64) > > in which the tcp header size would overflow 128 bytes. > > > > --- > &

Re: Memory Protection project interface details (GSoC 2020)

Hello Utkarsh, I'd suggest you don't spend too much efforts on setting up BBB hardware if you haven't already. Debugging on QEMU with GDB is way easier, and you can consider either qemu-xilinx-zynq-a9 or rpi2 BSPs. Later, you can move your code to BBB if you want, since both are based on ARMv7.

Re: clang sparc: generated .o file incompatible with elf64-x86-64

Have you seen that? https://stackoverflow.com/questions/19118854/unable-to-cross-compile-to-sparc-using-clang I’m not sure sparc backend is well supported by clang/llvm. Try with riscv. On Mon, 4 May 2020 at 13:34, Hesham Almatary wrote: > > > On Mon, 4 May 2020 at 13:19, Joel Sherri

Re: clang sparc: generated .o file incompatible with elf64-x86-64

On Mon, 4 May 2020 at 13:19, Joel Sherrill wrote: > > > On Mon, May 4, 2020, 7:16 AM suyash singh > wrote: > >> I am trying to cross compile with clang and run Undefined Behavior >> Sanitizer for .c file >> >> *Command I am running* >> >> clang -target sparc -integrated-as -fuse-ld=lld

Re: rtems assembler

-elf > https://hastebin.com/jirusidoti.sql > different error: unknown register name (maybe because erc32 bsp with > riscv) > Yes, you need to run that on an RTEMS riscv BSP and not sparc sources > > On Thu, Apr 30, 2020 at 8:08 PM Hesham Almatary > wrote: > >> >> &g

Re: rtems assembler

me error > /usr/bin/as: unrecognized option '-Av8' > clang-11: error: assembler command failed with exit code 1 > > If i write > clang -target hello test1.c > error: unknown target triple 'hello', please use -triple or -arch > > So I guess it is detecting sparc bu

Re: rtems assembler

le) > subprocess.run(arr,cwd=relativedir, stdout=subprocess.PIPE) > #result=subprocess.run(['./a.out'],cwd=relativedir, stdout=subprocess.PIPE) > > On Thu, Apr 30, 2020 at 6:44 PM Hesham Almatary > wrote: > >> >> >> On Thu, 30 Apr 2020 at 13:51, Joel Sherrill wrote

Re: rtems assembler

On Thu, 30 Apr 2020 at 13:51, Joel Sherrill wrote: > > > On Thu, Apr 30, 2020 at 7:34 AM suyash singh > wrote: > >> Hello, >> I was running clang UBSan on >> bsps/sparc/erc32/btimer/btimer.c >> >> and got error >> >> /usr/bin/as: unrecognized option '-Av8' >> clang-11: error: assembler command

Re: rtems assembler

On Thu, 30 Apr 2020 at 13:34, suyash singh wrote: > Hello, > I was running clang UBSan on > bsps/sparc/erc32/btimer/btimer.c > What’s the command line you're using? > and got error > > /usr/bin/as: unrecognized option '-Av8' > clang-11: error: assembler command failed with exit code 1 > > I am

Re: [PATCH] build: output COMPILER for each variant in bsp_defaults

On Sun, 12 Apr 2020 at 17:10, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 11/04/2020 17:52, Hesham Almatary wrote: > > > Build multiple BSPs would fail without this patch as COMPILER > > is only being emitted once at the end of config.ini (last BSP).

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

On Fri, 10 Apr 2020 at 21:08, Sebastian Huber wrote: > > 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

[PATCH] build: output COMPILER for each variant in bsp_defaults

Build multiple BSPs would fail without this patch as COMPILER is only being emitted once at the end of config.ini (last BSP). --- wscript | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/wscript b/wscript index c763e214f..d4ca98afb 100755 --- a/wscript +++ b/wscript @@

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

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

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

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

  1   2   3   4   5   >