FW: rtems on nios2 collaborative efforts

[Gedare Bloom]

If these don't get picked up you might want to post a PR in bugzilla
and attach them there as well.

-Gedare

On Thu, Jul 12, 2012 at 11:52 AM, Hill, Jeff <johill at lanl.gov> wrote:
> Hello,
>
> Attached are some git patch files for RTEMS and Altera Nios2 Softcore. Let me know if you have any questions about these changes/additions or if there is a better format to submit patches in.
>
> Jeff Hill
>
>> -----Original Message-----
>> From: Sebastian Huber [mailto:sebastian.huber at embedded-brains.de]
>> Sent: Friday, March 30, 2012 7:18 AM
>> To: Hill, Jeffrey O; rtems-devel at rtems.org
>> Cc: rtemsdev at ixo.de; ruppe at kth.se
>> Subject: Re: FW: rtems on nios2 collaborative efforts
>>
>> Hello Jeffrey,
>>
>> On 03/29/2012 06:25 PM, Hill, Jeffrey O wrote:
>> >
>> > -----Original Message-----
>> > From: Hill, Jeffrey O
>> > Sent: Wednesday, March 28, 2012 4:25 PM
>> > To: 'rtemsdev at ixo.de'
>> > Cc: 'ruppe at kth.se'; 'rtems-devel at rtems.org'
>> > Subject: rtems on nios2 collaborative efforts
>> >
>> > Hello all,
>> >
>> > My name is Jeff Hill, I work for LANSCE Accelerator project in Los
>> Alamos USA, and I have been working on the nios2 RTEMS source code some
>> over the last year and have implemented some new functionality.
>> >
>> > o Altera Avalon TSE Ethernet driver
>> > o Altera Avalon SGDMA driver
>> > o RTEMS Ethernet interface driver using Altera Avalon TSE and Altera
>> Avalon SGDMA
>> > o GDB stub for nios2. This provides RTEMS thread aware debugging, and
>> one can attach from a 2nd jtag uart in the design so it doesn't
>> necessarily replace, or interfere with the Altera supplied gdb.
>>
>> nice.
>>
>> > o exception cause detection if the nios2 isn't instantiated with "extra
>> exception information"
>>
>> I use only the generated code from Altera in this area.  Also our FPGA has
>> the
>> extra exception information, so I cannot say much to this.
>>
>> > o nios2 exception vectoring
>>
>> What do you mean with this?  I didn't look at the internal interrupt
>> controller
>> (IIC) stuff, since we use the external interrupt controller (EIC) with
>> shadow
>> registers.
>>
>> > o termios interface with both polled and interrupt driven interfaces for
>> the Altera Avalon JTAG UART
>> > o A alternative BSP with simplified auto-configuration based on
>> compiling a host tool that directly includes system.h (maybe this wasn't
>> really a good idea because I know you have already implemented ptf file
>> style auto-configuration, but I couldn't find a ptf file that was being
>> generated by QSYS). However, if we can agree on the device parameter macro
>> naming scheme used by the BSP device drivers then perhaps both approaches
>> can coexist?
>>
>> We have probably something similar in a not published BSP which is
>> automatically generated from the FPGA specifications.   We use heavily the
>> Altera HAL for this.
>>
>> > o Moving the BSP device drivers to a common shared subdirectories off of
>> libbsp/nios2/shared
>>
>> Ok.
>>
>> >
>> > I am also currently working on the internal interrupt controller ISR
>> handler
>> > o there appear to be some race conditions in the code I received
>> > o possibly the code should be repackaged so all of it is in assembler.
>> That might make the race conditions easier to understand?
>> > o I have written a code that determines the interrupt vector number
>> based on the lowest-bit-set in the interrupt pending register with less
>> cpu overhead and more deterministic delay compared with the previous
>> assembler loop code (I suspect you may be working on this also).
>> > o I have also written some code to mask out interrupts of equal or lower
>> interrupt level when the user's isr is running, but allow higher level
>> interrupts to preempt.
>>
>> I only looked briefly at the IIC code and think that there are a number of
>> issues with the current code.  We use the EIC, thus I didn't investigate
>> this
>> further.  I have also no ability to test this.
>>
>> > In any case I just now noticed that there have been some commits in
>> September against the NIOS2 support in RTEMS so I decided that I will need
>> to sync up with your efforts. I will be looking closely at what you have
>> done since my snapshot in February of last year.
>> >
>> > In summary I am writing this message to see if we might work together
>> and make faster progress.
>>
>> Ok, great.  You can send patches to rtems-devel at www.rtems.org (e.g. with
>> git
>> format-patch + git send-email).  Please use one commit for one atomic
>> change
>> set so the review and integration is easier.
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>> Phone   : +49 89 18 90 80 79-6
>> Fax     : +49 89 18 90 80 79-9
>> 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.
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>