Hello,
the bsp_interrupt_dispatch() is quite complicated in the beagle BSP. Is
the interrupt controller of this chip really that broken? Sane interrupt
controllers block interrupts of equal or lower priority relative to the
currently pending interrupt.
On 28/05/15 13:14, ragu nath wrote:
Hi Ben,
I found the reason for system hang in BBB after link goes up. It is
caused by enabling the interrupt before it is processed creating a
continuous flow of interrupts hogging the CPU.
In rtems-libbsd we do not directly call the interrupt handler. we
create an event through interrupt trigger routine and then the server
task detects the event and calls the actual intr handler. While
registering the interrupt, we will give this trigger routine as
handler. Server task separately calls the actual intr handler.
In BBB irq processing (bsp_interrupt_dispatch function), we disable
the vector and call the handler and enable it.
For network interrupt intr, this handler will be interrupt trigger
routine which creates an event. After this intr is enabled but the
interrupt was not processed. The intr was supposed to be enabled by
the server task after processing the interrupt. This causes the hang.
The irq dispatch function assumes that we are calling the actual intr
handler and enables the interrupt. But since we are processing the
interrupt in a separate server task, it needs to be enabled there not
in the dispatch function.
As a temp fix, I selectively disabled bsp_interrupt_vector_enable in
dispatch function. There is no hang and packets are received.
What can be the correct fix for the issue as there are other
interrupts that are not processed in this way?
Thanks,
Ragunath
On Fri, May 15, 2015 at 12:39 PM, ragu nath <ragunath3...@gmail.com> wrote:
Thank you. I will check the git log. I am also inclined to using nexus
support. I already compiled the driver using nexus support. I fully
intend to add more documentation to the project. I will keep posting
on this thread if I have any further issues.
Thanks,
Ragunath
On Fri, May 15, 2015 at 12:05 PM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
You have two options.
1. You port simplebus to libbsd. I tried this before and its not done in one
day.
2. You get rid of all simplebus dependencies in the driver and use the
libbsd nexus support. This is normally done in a couple of minutes with the
use some hacks to get the FDT provided parameters.
To get an idea how a driver is ported see git log and look at all commits
containing "if_cgem" in the subject.
Please help to improve the documentation (libbsd.txt) while you work on this
topic.
On 15/05/15 08:27, ragu nath wrote:
Hi All,
My name is ragunath. I am selected for Google Summer of Code 2015 with
RTEMS. I will be working on improving Beagle BSP.
I am in the process of porting ethernet driver for Beaglebone black
from FreeBSD to rtems-libbsd. I would like to know what are the
necessary changes we need to make to add a driver. BBB is based on ARM
Am335x SoC.
What are the bsp specific changes we need to do (bus support api's,
interrupt support, etc)? I understand all the devices are under nexus
device in rtems-libbsd. In the FreeBSD code, it is under simplebus.
What are the changes we need to do to take care of this?
If there is any documentation available on this topic pls let me know.
Thanks,
Ragunath
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
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...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
--
ragu
--
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...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
