Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
Hello Padmarao,
On 03.03.23 15:55, padmarao.beg...@microchip.com wrote:
On Thu, 2023-03-02 at 15:18 +0100, Sebastian Huber wrote:
On 27.02.23 16:51, Padmarao Begari wrote:
The interrupt complete should clear with the interrupt
number before disabling the interrupt in the PLIC to
get the next interrupt.
Which problem does this patch address?
The problem occurs when the interrupt register(enabled) in the RTEMS-
LIBBSD drivers and want to serve the interrupt subroutine in the RTEMS.
Example : CGEM driver
When the application running to test the CGEM driver with RTEMS +
RTEMS-LIBBSD, The interrupt is occurred while transmiting the ethernet
pocket, the RTEMS is received the interrupt but not served with the
register interrupt subroutine instead it disable the interrupt and set
the "RTEMS_EVENT_SYSTEM_SERVER", while completing the ISR it is
clearing the interrupt complete register but there is no effect and the
next transmit pocket intereupt is not occurred because the interrupt is
disabled before the interrupt complete clear.
RISC-V interrupt stacktrace
**
_RISCV_Exception_handler()
_RISCV_Interrupt_dispatch()
bsp_interrupt_handler_dispatch_unchecked()
bsp_interrupt_dispatch_entries()
( *entry->handler )( entry->arg ); -> bsp_interrupt_server_trigger()
bsp_interrupt_server_trigger()
bsp_interrupt_is_valid_vector()
bsp_interrupt_vector_disable()
rtems_event_system_send()
*
The claim complete register is written after the interrupt handler dispatch:
while ((interrupt_index = plic_hart_regs->claim_complete) != 0) {
bsp_interrupt_handler_dispatch(
RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
);
plic_hart_regs->claim_complete = interrupt_index;
If you write to the claim complete register also in the interrupt
disable function, then this write is done twice.
The interrupt disable function may be used in other contexts as well so
doing a write to the claim complete register may have unexpected side
effects.
We should first figure out why the current implementation which works
with several other interrupt controllers doesn't work with the PLIC. Is
the claim complete message ignored if the interrupt is disabled?
--
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: RTEMS LwIP licensing and organization cleanup proposal - actual Ti code license
Hello Joel and Gedare On Friday 03 of March 2023 14:32:33 Pavel Pisa wrote: > The RTEMS core integration layer is held in uLan/ports/os/rtems > subdirectory > > https://git.rtems.org/rtems-lwip/tree/uLan/ports/os/rtems/arch/sys_arch.c > > It should be moved somewhere else, i.e. under > > https://git.rtems.org/rtems-lwip/tree/rtemslwip/common > ... > To make integration with RTEMS easier, the source should > be relicensed to some common actual RTEMS license template, > for example > > https://git.rtems.org/rtems/tree/bsps/arm/lpc176x/start/bspstart.c > > We have referenced Swedish Institute of Computer Science license > there to allow integration even to some official LwIP port > but except for function and defines names the code is our own > so RTEMS copyright with reference to implementation inspired by > other LwIP OS integration should be OK. > > I have contacted Premysl Houdek who worked on project during > his RTEMS GSoC and followup diploma thesis > > > https://support.dce.felk.cvut.cz/mediawiki/images/f/f1/Dp_2016_houdek_premy >sl.pdf > > and he is prepared to confirm relicensing to any RTEMS fitting > open source license. > > For actual RTEMS LwIP users and contributors, please propose license change > or chose some of above offers and then propose new files location including > git patches or I can take that action if > So we have right relicense all uLAN OMK remains except for Ti PHY files and registers for TMS570 EMAC (actual controller driver is ours). The original Ti files with license to check are there https://git.rtems.org/rtems-lwip/tree/uLan/ports/driver/tms570_emac/ti_drv_emac.h Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ company:https://pikron.com/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CAN driver implementation for Xilinx Zynq
Dear Carlo and others, On Friday 03 of March 2023 16:03:52 Gedare Bloom wrote: > On Wed, Mar 1, 2023 at 3:14 AM wrote: > > As part of an internship at the German Aerospace Center, I am currently > > working on the implementation of a CAN driver for a Xilinx Zynq SoC. For > > this I used the existing CAN framework /dev/can/can.h. A merge request > > will follow soon. > > > > > > Here's what I'd like to add to the framework if it hasn't already been > > done: > > > > * RxFIFO. Currently can_bus_read only stores the latest CAN message in > > can_bus->can_rx_msg. There is a FIXME note on this in can.c, line 188, > > but I couldn't find an implementation of it. > > This will be great. Other issues to address in this code base are the > lack of integration with existing RTEMS functionality. Especially > helpful would be to add message queue abstraction layer along with > making a more proper device driver structure. Message queue has the > advantage that it can take care of handling multiple priorities and > synchronization, and reduces the code size and maintenance burden. > > You can see an interface/implementation like this in: > https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/mscan or look at https://sourceforge.net/p/ortcan/lincan/ci/master/tree/ and related documentation https://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf The actual RTEMS can-msg.h has updated version which is prepared for CAN FD for future and has been confirmed by me and Oliver Hartkopp (Linux SocketCAN author) as fitting well to RTEMS https://git.rtems.org/rtems/tree/cpukit/include/dev/can/can-msg.h I think that concept of queues in LinCAN is right for char driver CAN drivers and it worth and could be ported to RTEMS easily. Important question is, if to use CAN specific FIFOs implementation https://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/include/can_queue.h or change it to some RTEMS or POSIX queue. That is main point to decide. Then porting of LinCAN code to RTEMS is easy a as main contributor, architecture and mechanism architects etc. I can change license to BSD 2 clauses for RTEMS. Even actual LinCAN license is GPL2 with linking exception to be compatible with RTEMS from the project beginning. By the way, I we have lot of experience with Zynq Zynq 7000 SoCs, its XCAN and even own CTU CAN FD on it under GNU/Linux https://canbus.pages.fel.cvut.cz/ I have tested RTEMS on it in 2017 and with Michal Lenc, my studnet, we have tested actual RTEMS on it at end of 2022 year for motion control with TCP/IP. I can help with advice or even some contributions but important is decision what should be right implementation and how much effort and skills would be invested. I have kept my push at low level during last summer due to my load by other projects and fear, that if I will demand to high level, then it would be hard to implement it and may be full LinCAN like solution with multiple open supported, filtering etc is too complex. But is we can agree on some level I can help to get to that. I think that porting of LinCAN queues to RTEMS is easy task and I can try that in my spare time... I would really to see future-proof CAN/CAN FD support in RTEMS. But on the other hand, I have limited resources, no RTEMS active product at moment, and I understand that others resources are limited too. But on Zynq, I have easy way to test. We have designed and delivered 42 education kits using MicroZed to the university and I have some more produced for myself https://cw.fel.cvut.cz/wiki/courses/b35apo/en/documentation/mz_apo/start Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ company:https://pikron.com/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
