FW: rtems on nios2 collaborative efforts

Sebastian Huber sebastian.huber at embedded-brains.de
Fri Mar 30 13:17:38 UTC 2012


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.



More information about the devel mailing list