Porting ethernet driver from FREEBSD to rtems-libbsd

[ragu nath]

Hi Sebastian,

The problem is with rx interrupt. We are enabling rx interrupt before
it is processed. The rtems server task do not get an opportunity to
run.

I found this might be the logical explanation of the issue.
bsp_interrupt_dispatch() calls bsp_interrupt_server_trigger which
disables the rx interrupt and creates BSP_INTERRUPT_EVENT .  For this
event, bsp_interrupt_server_task() was supposed to call the actual
interrupt handler and then enable the rx interrupt. But before the
event is processed, we enable the rx interrupt in dispatch function.
So again rx interrupt is generated and event is created and the cycle
goes on. Server task is never executed in turn actual interrupt
handler is never executed.

Since we enable the interrupt, it occurs again and again as we never handle it.

Is there any other possibility that I might need to look into?


Thanks,
Ragunath

On Thu, May 28, 2015 at 4:58 PM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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 <ragunath3252 at 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.huber at 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 at 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.huber at 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>



-- 
ragu