[PATCH 1/1] Fixed a typo in the /user/bsps/arm/stm32h7.rst file.
--- user/bsps/arm/stm32h7.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/bsps/arm/stm32h7.rst b/user/bsps/arm/stm32h7.rst index 9f1f082..6257e0d 100644 --- a/user/bsps/arm/stm32h7.rst +++ b/user/bsps/arm/stm32h7.rst @@ -248,7 +248,7 @@ installed. Please go to its *bin* directory. E.g. $ cd plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.200.202202231230/tools/bin Now, you will need to edit provided *config.txt* file inside the -directory. Use your favorite editor. Open the file and scrolls +directory. Use your favorite editor. Open the file and scroll down to its end. You will see following comment: .. code-block:: none -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 0/1] Fix a typo in the stm32h7 BSP Documentation
Hi, I found a small typo while going through the BSP documentation for stm32h7 and fixed it in this commit. Thank You Ruturaj Nanoti (1): Fixed a typo in the /user/bsps/arm/stm32h7.rst file. user/bsps/arm/stm32h7.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] bsps/riscv: add riscv/kendrytek210 BSP variant
>> >> > diff --git a/bsps/riscv/riscv/start/bspstart.c
>> >> > b/bsps/riscv/riscv/start/bspstart.c
>> >> > index 30d479ce88..a0b6e683f6 100644
>> >> > --- a/bsps/riscv/riscv/start/bspstart.c
>> >> > +++ b/bsps/riscv/riscv/start/bspstart.c
>> >> > @@ -201,6 +201,14 @@ static uint32_t get_core_frequency(void)
>> >> > return fdt32_to_cpu(*val);
>> >> >}
>> >> > #endif
>> >> > +
>> >> > +#if RISCV_ENABLE_KENDRYTE_K210_SUPPORT != 0
>> >> > + uint32_t cpu_clock;
>> >> > +
>> >> > + cpu_clock = k210_get_frequency();
>> >> > + return cpu_clock;
>> >> > +#endif
>> >> > +
>> >> >return 0;
>> >
>> >
>> > When you choose the kendrtyek210 BSP variant, the
>> > RISCV_ENABLE_KENDRYTE_K210_SUPPORT is set to true enabling the code that
>> > is needed for frequency calculation in this file. I tried to follow the
>> > same pattern for the MPFS and FRDME310ARTY variants here.
>> > The K210, FRME310ARTY, and MPFS options could probably use refactoring,
>> > but I was reluctant to change existing code for the MPFS and 310ARTY since
>> > I do not have a way of testing them.
>> >
>> I would at a minimum make it #else return 0
>> to avoid having unreachable code in your build.
>>
>
> The "return 0" is right after my ifdef block. If I put #else return 0, then
> there will be two "return 0" statements.
> If none of the variant options are defined, then the entire routine defaults
> to "return 0" at the bottom.
> Should I eliminate that and put the else clauses for the FRDME310ARTY and
> MPFS variants too?
I meant to put the 'return 0;' in an #else
That will leave the tail of the function with just one return
statement, dependent on the CPP macro conditional.
#if RISCV_ENABLE_KENDRYTE_K210_SUPPORT != 0
uint32_t cpu_clock;
cpu_clock = k210_get_frequency();
return cpu_clock;
#else
return 0;
#endif
This will avoid having a dead code issue. The other blocks above don't
need to be modified.
> Thanks,
> Alan
>
>>
>>
>> >
>> >> This code is unreachable if RISCV_ENABLE_KENDRYTE_K210_SUPPORT != 0.
>> >>
>> >> > }
>> >> >
>> >> > @@ -215,6 +223,40 @@ uint32_t bsp_fdt_map_intr(const uint32_t *intr,
>> >> > size_t icells)
>> >> >return RISCV_INTERRUPT_VECTOR_EXTERNAL(intr[0]);
>> >> > }
>> >> >
>> >> > +#if RISCV_ENABLE_KENDRYTE_K210_SUPPORT != 0
>> >> > +uint32_t k210_get_frequency(void)
>> >> > +{
>> >> > + k210_sysctl_t *sysctl = (k210_sysctl_t *)K210_SYSCTL_BASE;
>> >> > + uint32_t cpu_clock = 0;
>> >> > + uint32_t clk_freq;
>> >> > + uint32_t pll0, nr, nf, od;
>> >> > + uint32_t node;
>> >> > + const char *fdt;
>> >> > + const fdt32_t *val;
>> >> > + int len;
>> >> > +
>> >> > + fdt = bsp_fdt_get();
>> >> > + node = fdt_node_offset_by_compatible(fdt, -1,"fixed-clock");
>> >> > + val = fdt_getprop(fdt, node, "clock-frequency", );
>> >> > + if (val != NULL && len == 4) {
>> >> > +clk_freq = fdt32_to_cpu(*val);
>> >> > +
>> >> > +if (CLKSEL0_ACLK_SEL(sysctl->clk_sel0) == 1) {
>> >> > + /* PLL0 selected */
>> >> > + pll0 = sysctl->pll0;
>> >> > + nr = PLL_CLK_R(pll0) + 1;
>> >> > + nf = PLL_CLK_F(pll0) + 1;
>> >> > + od = PLL_CLK_OD(pll0) + 1;
>> >> > + cpu_clock = (clk_freq / nr * nf / od)/2;
>> >> > +} else {
>> >> > + /* OSC selected */
>> >> > + cpu_clock = clk_freq;
>> >> > +}
>> >> > + }
>> >> > + return cpu_clock;
>> >> > +}
>> >> > +#endif
>> >> > +
>> >> > void bsp_start(void)
>> >> > {
>> >> >riscv_find_harts();
>> >> > --
>> >> > 2.25.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 rtems-source-builder] rtems-tools-6.cfg: Update to get RISC-V bsp-builder corrections
---
rtems/config/tools/rtems-tools-6.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/rtems/config/tools/rtems-tools-6.cfg
b/rtems/config/tools/rtems-tools-6.cfg
index 8cd4bb1..042e0fa 100644
--- a/rtems/config/tools/rtems-tools-6.cfg
+++ b/rtems/config/tools/rtems-tools-6.cfg
@@ -10,14 +10,14 @@
%define rtems_tools_source rtems-tools-%{rtems_tools_version}
%define rtems_tools_ext xz
%else
- %define rtems_tools_version 0b9bb40e766228cf957adea417be5870bfe18980
+ %define rtems_tools_version c8bf7309332990a52ae98ed3926c0f62984e8193
%define rtems_tools_ext bz2
%endif
%define rtems_tools_source rtems-tools-%{rtems_tools_version}
%source set rtems-tools
https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
%hash sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
-
8e034f0922e1b48ca0b1553f96cc786e25b4992e21a744f0beb1c30affb474816ffcb5ec8833401a78b4e92a656eedc845316596dc4a1d4b8eb75cc8d77fed18
+
XOCIuPQ65yZOvPkiTZb3r2T9YAPBg6az3xz5Z2ivkfygSYZgaymSkmpv5yF3QbCXK1Y+2LRUuEp73oymj7vnbA==
#
# Optionally enable/disable building the RTEMS Tools via the command line.
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
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 +++- >> > 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 >> > --- a/config/rtems-bsps-riscv.ini >> > +++ b/config/rtems-bsps-riscv.ini >> > @@ -1,6 +1,7 @@ >> > # >> > # RTEMS Tools Project (http://www.rtems.org/) >> > # Copyright 2018 embedded brains GmbH >> > +# Copyright 2022 OAR Corporation >> > # All rights reserved. >> > # >> > # This file is part of the RTEMS Tools package in 'rtems-bsp-builder'. >> > @@ -22,8 +23,13 @@ >> > # >> > [riscv] >> > bsps = frdme310arty, >> > - griscv, grv32i, grv32im, grv32imac, grv32imafdc, >> > - rv32iac, rv32i, rv32imac, rv32imafc, rv32imafdc, rv32imafd, rv32im, >> > - rv64imac, rv64imac_medany, rv64imafdc, rv64imafd, >> > rv64imafdc_medany, >> > - rv64imafd_medany >> > -exclude-smp = rv32i, rv32im >> > +griscv, grv32i, grv32im, grv32imac, grv32imafdc, >> > +mpfs64imafdc, >> > +noel32im, noel32imafd, noel64imac, noel64imafd, noel64imafdc, >> > +rv32i, rv32iac, rv32im, rv32imac, rv32imafc, rv32imafd, rv32imafdc, >> Could we make sure that only variants in multilib are here? For >> example, there shouldn't be rv32imafdc. I submitted a similar patch >> before here [1], please feel free to use it as a reference as in to >> what multilib variants should be used here. > > > This list is based on what is currently in RTEMS. Kinsey and I started with > the > list reported by "rtems-bsps -a riscv" and reviewed which has SMP as an > option. > > Given that you know the riscv much better, I would politely request that you > let > me push this and then you follow up with patches to remove those BSPs from > rtems and rtems-tools. > Definitely yes, feel free to push, thanks for checking with me. > --joel >> >> >> [1] https://lists.rtems.org/pipermail/devel/2023-February/074455.html >> >> > +rv64imac, rv64imafd, rv64imafdc >> > + >> > +exclude-smp = frdme310arty, >> > +grv32i, grv32im, >> > +noel32im, >> > +rv32i, rv32im >> > -- >> > 1.8.3.1 >> > >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> >> >> >> -- >> Regards, >> Hesham -- Regards, Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] rtems-bsps-riscv.ini: Update list to drop medany and add BSPs
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 +++- > > 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 > > --- a/config/rtems-bsps-riscv.ini > > +++ b/config/rtems-bsps-riscv.ini > > @@ -1,6 +1,7 @@ > > # > > # RTEMS Tools Project (http://www.rtems.org/) > > # Copyright 2018 embedded brains GmbH > > +# Copyright 2022 OAR Corporation > > # All rights reserved. > > # > > # This file is part of the RTEMS Tools package in 'rtems-bsp-builder'. > > @@ -22,8 +23,13 @@ > > # > > [riscv] > > bsps = frdme310arty, > > - griscv, grv32i, grv32im, grv32imac, grv32imafdc, > > - rv32iac, rv32i, rv32imac, rv32imafc, rv32imafdc, rv32imafd, > rv32im, > > - rv64imac, rv64imac_medany, rv64imafdc, rv64imafd, > rv64imafdc_medany, > > - rv64imafd_medany > > -exclude-smp = rv32i, rv32im > > +griscv, grv32i, grv32im, grv32imac, grv32imafdc, > > +mpfs64imafdc, > > +noel32im, noel32imafd, noel64imac, noel64imafd, noel64imafdc, > > +rv32i, rv32iac, rv32im, rv32imac, rv32imafc, rv32imafd, rv32imafdc, > Could we make sure that only variants in multilib are here? For > example, there shouldn't be rv32imafdc. I submitted a similar patch > before here [1], please feel free to use it as a reference as in to > what multilib variants should be used here. > This list is based on what is currently in RTEMS. Kinsey and I started with the list reported by "rtems-bsps -a riscv" and reviewed which has SMP as an option. Given that you know the riscv much better, I would politely request that you let me push this and then you follow up with patches to remove those BSPs from rtems and rtems-tools. --joel > > [1] https://lists.rtems.org/pipermail/devel/2023-February/074455.html > > > +rv64imac, rv64imafd, rv64imafdc > > + > > +exclude-smp = frdme310arty, > > +grv32i, grv32im, > > +noel32im, > > +rv32i, rv32im > > -- > > 1.8.3.1 > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > > > -- > Regards, > Hesham > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Help for GSoC proposal
Hey there, I am thinking of taking #4628 for adding SATA support in libbsd for RTEMS as my GSoC 2023 Project. I have already done the Hello World patch and sent the screenshot to gedare and DrRTEMS. This is my first time in GSoC so it would be a great help if someone could guide me. Thanks & Regards Hardik Sethi ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V link warning :base_sp.exe has a LOAD segment with RWX permissions
Probably a new binutils made by: commit c58857dfdd8830871236261a3ef8399eff3b9b68 Author: Joel Sherrill Date: Tue Feb 21 09:24:37 2023 -0600 Update to binutils 2.40 for rtems 6 Karel On 3/14/23 15:45, Alan Cudmore wrote: Hi, I noticed that my RISC-V builds with the RTEMS master and RSB master now have this warning on each link: [3405/4331] Linking build/riscv/rv64imafdc/testsuites/samples/minimum.exe /home/alan/rtems/tools/6/lib/gcc/riscv-rtems6/12.2.1/../../../../riscv-rtems6/bin/ld: warning: /home/alan/rtems/rtems/build/riscv/rv64imafdc/testsuites/samples/base_sp.exe has a LOAD segment with RWX permissions I was trying to back up commits in the RTEMS and RSB repositories to see when it started, but I have not figured it out yet. My host is Ubuntu 20.04.1 LTS x86_64. Thanks, Alan ___ 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
RISC-V link warning :base_sp.exe has a LOAD segment with RWX permissions
Hi, I noticed that my RISC-V builds with the RTEMS master and RSB master now have this warning on each link: [3405/4331] Linking build/riscv/rv64imafdc/testsuites/samples/minimum.exe /home/alan/rtems/tools/6/lib/gcc/riscv-rtems6/12.2.1/../../../../riscv-rtems6/bin/ld: warning: /home/alan/rtems/rtems/build/riscv/rv64imafdc/testsuites/samples/base_sp.exe has a LOAD segment with RWX permissions I was trying to back up commits in the RTEMS and RSB repositories to see when it started, but I have not figured it out yet. My host is Ubuntu 20.04.1 LTS x86_64. Thanks, Alan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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 > --- a/config/rtems-bsps-riscv.ini > +++ b/config/rtems-bsps-riscv.ini > @@ -1,6 +1,7 @@ > # > # RTEMS Tools Project (http://www.rtems.org/) > # Copyright 2018 embedded brains GmbH > +# Copyright 2022 OAR Corporation > # All rights reserved. > # > # This file is part of the RTEMS Tools package in 'rtems-bsp-builder'. > @@ -22,8 +23,13 @@ > # > [riscv] > bsps = frdme310arty, > - griscv, grv32i, grv32im, grv32imac, grv32imafdc, > - rv32iac, rv32i, rv32imac, rv32imafc, rv32imafdc, rv32imafd, rv32im, > - rv64imac, rv64imac_medany, rv64imafdc, rv64imafd, rv64imafdc_medany, > - rv64imafd_medany > -exclude-smp = rv32i, rv32im > +griscv, grv32i, grv32im, grv32imac, grv32imafdc, > +mpfs64imafdc, > +noel32im, noel32imafd, noel64imac, noel64imafd, noel64imafdc, > +rv32i, rv32iac, rv32im, rv32imac, rv32imafc, rv32imafd, rv32imafdc, Could we make sure that only variants in multilib are here? For example, there shouldn't be rv32imafdc. I submitted a similar patch before here [1], please feel free to use it as a reference as in to what multilib variants should be used here. [1] https://lists.rtems.org/pipermail/devel/2023-February/074455.html > +rv64imac, rv64imafd, rv64imafdc > + > +exclude-smp = frdme310arty, > +grv32i, grv32im, > +noel32im, > +rv32i, rv32im > -- > 1.8.3.1 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Regards, Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-tools] rtems-bsps-riscv.ini: Update list to drop medany and add BSPs
--- 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 --- a/config/rtems-bsps-riscv.ini +++ b/config/rtems-bsps-riscv.ini @@ -1,6 +1,7 @@ # # RTEMS Tools Project (http://www.rtems.org/) # Copyright 2018 embedded brains GmbH +# Copyright 2022 OAR Corporation # All rights reserved. # # This file is part of the RTEMS Tools package in 'rtems-bsp-builder'. @@ -22,8 +23,13 @@ # [riscv] bsps = frdme310arty, - griscv, grv32i, grv32im, grv32imac, grv32imafdc, - rv32iac, rv32i, rv32imac, rv32imafc, rv32imafdc, rv32imafd, rv32im, - rv64imac, rv64imac_medany, rv64imafdc, rv64imafd, rv64imafdc_medany, - rv64imafd_medany -exclude-smp = rv32i, rv32im +griscv, grv32i, grv32im, grv32imac, grv32imafdc, +mpfs64imafdc, +noel32im, noel32imafd, noel64imac, noel64imafd, noel64imafdc, +rv32i, rv32iac, rv32im, rv32imac, rv32imafc, rv32imafd, rv32imafdc, +rv64imac, rv64imafd, rv64imafdc + +exclude-smp = frdme310arty, +grv32i, grv32im, +noel32im, +rv32i, rv32im -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
On 14.03.23 14:37, padmarao.beg...@microchip.com wrote:
On Tue, 2023-03-14 at 13:37 +0100, Sebastian Huber wrote:
On 14.03.23 13:31,padmarao.beg...@microchip.com wrote:
Hi Sebastian,
On Mon, 2023-03-06 at 14:11 +0100, Sebastian Huber wrote:
On 06.03.23 13:00,padmarao.beg...@microchip.com wrote:
On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote:
On 06.03.23 10:24,padmarao.beg...@microchip.comwrote:
Hi Sebastian,
On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote:
On 06.03.23 09:37,padmarao.beg...@microchip.comwrote:
Is
the claim complete message ignored if the interrupt
is
disabled?
Yes.
Is this an intended and documented behaviour of the PLIC?
Not documented
Is this a common PLIC behaviour or just the case for the
MicroChip
implementation?
It's a common PLIC behaviour.
It is not implemented in the Qemu PLIC emulation:
https://github.com/qemu/qemu/blob/master/hw/intc/sifive_plic.c#L242
Where do I see this behaviour in a PLIC implementation, for
example:
https://github.com/lowRISC/opentitan/tree/master/hw/ip_templates/rv_plic
That the interrupt completion depends on the interrupt
enable/disable
status is quite unusual.
https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc#8-interrupt-completion
The interrupt is completed only when the interrupt is enabled but
not
when disabled.
Can we clear the interrupt before calling the interrupt handler?
like
below
https://github.com/RTEMS/rtems/blob/master/bsps/riscv/riscv/irq/irq.c#L90
while ((interrupt_index = plic_hart_regs->claim_complete) !=
0) {
+ plic_hart_regs->claim_complete = interrupt_index;
bsp_interrupt_handler_dispatch(
RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
);
- plic_hart_regs->claim_complete = interrupt_index;
Also refer
https://github.com/psherman42/Demonstrating-MTVEC/blob/main/start.s#L307
At some point I would like to enable support for nested interrupts. I
guess in this case it is important that you complete the interrupt
after
processing.
The Exception(trap) handler is called when an interrupt occurs and the
global interrupt(mie) is disabled automatically at the top-most
level–the MIE bit in mstatus and re-enabled after return from machine
interrupt instruction "mret".
I think, we will not get any other interrupt while servicing the
interrupt handler, we can use the interrupt complete before processing.
Currently yes, however, if we support nested interrupts then it would
look like this:
} else if (mcause == (RISCV_INTERRUPT_EXTERNAL_MACHINE << 1)) {
volatile RISCV_PLIC_hart_regs *plic_hart_regs;
uint32_t interrupt_index;
plic_hart_regs = cpu_self->cpu_per_cpu.plic_hart_regs;
while ((interrupt_index = plic_hart_regs->claim_complete) != 0) {
ENABLE MIE
bsp_interrupt_handler_dispatch(
RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
);
DISABLE MIE
plic_hart_regs->claim_complete = interrupt_index;
/*
* FIXME: It is not clear which fence is necessary here or if a
fence is
* necessary at all. The goal is that the complete signal is somehow
* recognized by the PLIC before the next claim is issued.
*/
__asm__ volatile ("fence o, i" : : : "memory");
}
The PLIC/CLINT combination is not really well suited for systems which
want to use interrupt priorities since the software and timer interrupts
bypass the PLIC interrupt priority handling. I don't know why hardware
developers can't stick with the best existing solutions instead of
reinventing the next second best solution.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
> On Tue, 2023-03-14 at 13:37 +0100, Sebastian Huber wrote:
>
> On 14.03.23 13:31, padmarao.beg...@microchip.com wrote:
> > Hi Sebastian,
> >
> > > On Mon, 2023-03-06 at 14:11 +0100, Sebastian Huber wrote:
> > >
> > >
> > > On 06.03.23 13:00,padmarao.beg...@microchip.com wrote:
> > > > > On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote:
> > > > >
> > > > > On 06.03.23 10:24,padmarao.beg...@microchip.com wrote:
> > > > > > Hi Sebastian,
> > > > > >
> > > > > > > On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote:
> > > > > > >
> > > > > > > On 06.03.23 09:37,padmarao.beg...@microchip.com wrote:
> > > > > > > > > Is
> > > > > > > > > the claim complete message ignored if the interrupt
> > > > > > > > > is
> > > > > > > > > disabled?
> > > > > > > > >
> > > > > > > > Yes.
> > > > > > > Is this an intended and documented behaviour of the PLIC?
> > > > > > Not documented
> > > > > Is this a common PLIC behaviour or just the case for the
> > > > > MicroChip
> > > > > implementation?
> > > > >
> > > > It's a common PLIC behaviour.
> > > It is not implemented in the Qemu PLIC emulation:
> > >
> > > https://github.com/qemu/qemu/blob/master/hw/intc/sifive_plic.c#L242
> > >
> > > Where do I see this behaviour in a PLIC implementation, for
> > > example:
> > >
> > > https://github.com/lowRISC/opentitan/tree/master/hw/ip_templates/rv_plic
> > >
> > > That the interrupt completion depends on the interrupt
> > > enable/disable
> > > status is quite unusual.
> > >
> > https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc#8-interrupt-completion
> > The interrupt is completed only when the interrupt is enabled but
> > not
> > when disabled.
> >
> > Can we clear the interrupt before calling the interrupt handler?
> > like
> > below
> > https://github.com/RTEMS/rtems/blob/master/bsps/riscv/riscv/irq/irq.c#L90
> >
> > while ((interrupt_index = plic_hart_regs->claim_complete) !=
> > 0) {
> > + plic_hart_regs->claim_complete = interrupt_index;
> >bsp_interrupt_handler_dispatch(
> > RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
> >);
> >
> > - plic_hart_regs->claim_complete = interrupt_index;
> >
> > Also refer
> > https://github.com/psherman42/Demonstrating-MTVEC/blob/main/start.s#L307
>
> At some point I would like to enable support for nested interrupts. I
> guess in this case it is important that you complete the interrupt
> after
> processing.
>
The Exception(trap) handler is called when an interrupt occurs and the
global interrupt(mie) is disabled automatically at the top-most
level–the MIE bit in mstatus and re-enabled after return from machine
interrupt instruction "mret".
I think, we will not get any other interrupt while servicing the
interrupt handler, we can use the interrupt complete before processing.
Regards
Padmarao
> Ideally, we would return a status in the interrupt handlers to
> support
> things like the PLIC, however, this would be an API change affecting
> all
> existing interrupt handlers. This is not an option from my side.
>
> I would add new BSP interrupt controller methods specifically for the
> interrupt server. By default, they do nothing. For the PLIC they do
> the
> enable and complete once the server task did process the interrupt.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas
> Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
On 14.03.23 13:31, padmarao.beg...@microchip.com wrote:
Hi Sebastian,
On Mon, 2023-03-06 at 14:11 +0100, Sebastian Huber wrote:
On 06.03.23 13:00,padmarao.beg...@microchip.com wrote:
On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote:
On 06.03.23 10:24,padmarao.beg...@microchip.com wrote:
Hi Sebastian,
On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote:
On 06.03.23 09:37,padmarao.beg...@microchip.com wrote:
Is
the claim complete message ignored if the interrupt is
disabled?
Yes.
Is this an intended and documented behaviour of the PLIC?
Not documented
Is this a common PLIC behaviour or just the case for the
MicroChip
implementation?
It's a common PLIC behaviour.
It is not implemented in the Qemu PLIC emulation:
https://github.com/qemu/qemu/blob/master/hw/intc/sifive_plic.c#L242
Where do I see this behaviour in a PLIC implementation, for example:
https://github.com/lowRISC/opentitan/tree/master/hw/ip_templates/rv_plic
That the interrupt completion depends on the interrupt enable/disable
status is quite unusual.
https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc#8-interrupt-completion
The interrupt is completed only when the interrupt is enabled but not
when disabled.
Can we clear the interrupt before calling the interrupt handler? like
below
https://github.com/RTEMS/rtems/blob/master/bsps/riscv/riscv/irq/irq.c#L90
while ((interrupt_index = plic_hart_regs->claim_complete) != 0) {
+ plic_hart_regs->claim_complete = interrupt_index;
bsp_interrupt_handler_dispatch(
RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
);
- plic_hart_regs->claim_complete = interrupt_index;
Also refer
https://github.com/psherman42/Demonstrating-MTVEC/blob/main/start.s#L307
At some point I would like to enable support for nested interrupts. I
guess in this case it is important that you complete the interrupt after
processing.
Ideally, we would return a status in the interrupt handlers to support
things like the PLIC, however, this would be an API change affecting all
existing interrupt handlers. This is not an option from my side.
I would add new BSP interrupt controller methods specifically for the
interrupt server. By default, they do nothing. For the PLIC they do the
enable and complete once the server task did process the interrupt.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
Hi Sebastian,
>On Mon, 2023-03-06 at 14:11 +0100, Sebastian Huber wrote:
>
>
> On 06.03.23 13:00, padmarao.beg...@microchip.com wrote:
> > > On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote:
> > >
> > > On 06.03.23 10:24,padmarao.beg...@microchip.com wrote:
> > > > Hi Sebastian,
> > > >
> > > > > On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote:
> > > > >
> > > > > On 06.03.23 09:37,padmarao.beg...@microchip.com wrote:
> > > > > > > Is
> > > > > > > the claim complete message ignored if the interrupt is
> > > > > > > disabled?
> > > > > > >
> > > > > > Yes.
> > > > > Is this an intended and documented behaviour of the PLIC?
> > > > Not documented
> > > Is this a common PLIC behaviour or just the case for the
> > > MicroChip
> > > implementation?
> > >
> > It's a common PLIC behaviour.
>
> It is not implemented in the Qemu PLIC emulation:
>
> https://github.com/qemu/qemu/blob/master/hw/intc/sifive_plic.c#L242
>
> Where do I see this behaviour in a PLIC implementation, for example:
>
> https://github.com/lowRISC/opentitan/tree/master/hw/ip_templates/rv_plic
>
> That the interrupt completion depends on the interrupt enable/disable
> status is quite unusual.
>
https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc#8-interrupt-completion
The interrupt is completed only when the interrupt is enabled but not
when disabled.
Can we clear the interrupt before calling the interrupt handler? like
below
https://github.com/RTEMS/rtems/blob/master/bsps/riscv/riscv/irq/irq.c#L90
while ((interrupt_index = plic_hart_regs->claim_complete) != 0) {
+ plic_hart_regs->claim_complete = interrupt_index;
bsp_interrupt_handler_dispatch(
RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
);
- plic_hart_regs->claim_complete = interrupt_index;
Also refer
https://github.com/psherman42/Demonstrating-MTVEC/blob/main/start.s#L307
Regards
Padmarao
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas
> Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] doxygen: Add groups for related test suites
On 13.03.23 22:57, Chris Johns wrote: Does this catch all RTEMSTestSuites cases? Thanks for the question. No, there were some places left over. I fixed this in the committed version. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
