FW: rtems on nios2 collaborative efforts
Hill, Jeff
johill at lanl.gov
Mon Aug 6 16:14:51 UTC 2012
Sebastian sent me some email last week indicating that he would
have a look at my patches.
Thanks,
Jeff
> -----Original Message-----
> From: gedare at gwmail.gwu.edu [mailto:gedare at gwmail.gwu.edu] On Behalf Of
> Gedare Bloom
> Sent: Monday, August 06, 2012 9:40 AM
> To: Hill, Jeff
> Cc: rtems-devel at www.rtems.org
> Subject: Re: FW: rtems on nios2 collaborative efforts
>
> 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
> >
More information about the devel
mailing list