FW: rtems on nios2 collaborative efforts

[Sebastian Huber]

On 03/30/2012 05:49 PM, Hill, Jeffrey O wrote:
>>> o nios2 exception vectoring
>>
>> What do you mean with this?
>
> I have added a nios2 specific interface in score/cpu/nios2 so that the application or BSP might install a handler to be called whenever a particular exception, with cause code nnn, is occurring. If only the default handler is installed it prints a message with a text description of the cause using vprintf (hopefully vprintf is appropriate in that role). This interface is used, for example, to attach the gdb stub to a trap instruction (I don't use the break instruction so that I won't clobber the Altera debugger).

You should use printk() in this context.

> Maybe this isn't correctly plumbed into RTEMS architecture? However I looked at the other CPU architectures and couldn't find (at least with a cursory search) any consistency when dealing with CPU exceptions (feel free to help me out if I am clueless on this point :-).

This is also my impression.

>
>>> 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.
>
> So in my revised version the cause field is pulled out of the exception register in assembler and is passed as the first argument to the C exception handler. Currently I have it testing (at runtime) in the C code to see if the cause code is zero (global reset), and if so it guesses that this isn't actually a global reset (hopefully that isn't a wrong guess) but instead that the extra exception information isn't instantiated in the nios2 CPU so it calls some additional C code that efficiently parses the instruction that is currently running (using jump tables) to determine the cause of the failure (as per the Altera manuals).
>
> I also wrote some small code that determines the correct IIC (internal interrupt controller) interrupt vector number form the ipending register without the long (maximum) delays associated with a 0 through 31 bit test loop. I used instead a binary search for the highest level IIC (internal interrupt controller) interrupt pending.
>
> I also have the set/get interrupt level codes testing to see if its external/internal interrupt controller. If it's the internal controller the interrupt level state is maintained in the ienable (the interrupt enable register), and otherwise if it's the external controller then the interrupt level state is in the status (and control) register. Currently I have it testing a single (internal/external interrupt controller) boolean variable even during interrupt level set/get which slows the code down for certain.

The current interrupt disable/enable code looks like this:

#define _CPU_ISR_Disable( _isr_cookie ) \
   do { \
     int _tmp; \
     __asm__ volatile ( \
       "rdctl %0, status\n" \
       "movhi %1, %%hiadj(_Nios2_ISR_Status_mask)\n" \
       "addi %1, %1, %%lo(_Nios2_ISR_Status_mask)\n" \
       "and %1, %0, %1\n" \
       "ori %1, %1, %%lo(_Nios2_ISR_Status_bits)\n" \
       "wrctl status, %1" \
       : "=&r" (_isr_cookie), "=&r" (_tmp) \
     ); \
   } while ( 0 )

#define _CPU_ISR_Enable( _isr_cookie ) \
   __builtin_wrctl( 0, (int) _isr_cookie )

#define _CPU_ISR_Flash( _isr_cookie ) \
   do { \
     int _status = __builtin_rdctl( 0 ); \
     __builtin_wrctl( 0, (int) _isr_cookie ); \
     __builtin_wrctl( 0, _status ); \
   } while ( 0 )

The _Nios2_ISR_Status_mask and _Nios2_ISR_Status_bits are symbols resolved at 
link time by the BSP.  This avoids a memory access.  The BSP knows if it works 
on a IIC or EIC configuration.

Please have a look at "nios2-isr-set-level.c".

> Is suppose that the best approach BTW would be to configure the NIOS2 options when configuring RTEMS so that score/cpu/nios2 code will not waste CPU executing run time tests discovering the nios2 options? There will be many nios2 specific options for FPU, MMU, MPU, EEI, IIC, EIC ...

I tried hard to configure everything at link or run-time time.  This keeps the 
cpukit free from conditional compilation.

Regarding the MPU, please have a look at "nios2-context-initialize.c" and 
_Nios2_MPU_Get_configuration().

-- 
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.